Write grant per atomic issuance #68
Conversation
| @@ -91,6 +91,16 @@ table write_grants { | |||
| foreign_key (wg_owner_user_id) references users(id) on_delete cascade | |||
| } | |||
|
|
|||
| table consumed_write_grants { | |||
There was a problem hiding this comment.
During the meeting, I'm pretty sure (but my memory sucks) that we settled on saving the whole message. So we either keep the message bytes, or we keep all the fields necessary to re-generate the message.
There was a problem hiding this comment.
In the meeting we decided that we need to prevent the following cases:
- Reuse consumed WG
- If there were
orig_idandcopy_idcredentials had created, and thenorig_idwas deleted, there is no way to recreateorig_id(and pair it withcopy_id) by the consumed or any other new WGs. - If there were
orig_idandcopy_idcredentials had created, and thencopy_idwas deleted, there is no way to recreatecopy_id(and pair it withorig_id) by the consumed or any other new WGs.
Also we agreed that User can create another WG (message) to allow to Issuer to create another instance of the same VC (with different orig_id and copy_id).
So to achieve prevent to reuse consumed WG the simplest way is to generate WG id by User and put it in the message. It is unique id and User can't put it in another WG. Storing message signature in consumed_write_grants also solve this requirement, but what the reason to do it this way if storing WG id is enough?
or we keep all the fields necessary to re-generate the message
Please remind me why we might need to re-generate the message?
There was a problem hiding this comment.
You are correct in your exposition, but (again, if I recall correctly) keeping the whole message was decided to sidestep the problem of "what fields should we keep around". I proposed that we don't make a decision for now, keep everything, and trim things in the future when we're more familiar with how people will want to use the system.
I'll also disambiguate this with Martin.
There was a problem hiding this comment.
There was a problem hiding this comment.
Added by this 3ec5a97
schema.development.kf
Outdated
| SELECT CASE WHEN (SELECT count(1) FROM access_grants WHERE id = uuid_generate_v5('31276fd4-105f-4ff7-9f64-644942c14b79'::uuid, format('%s-%s-%s', $grantee_wallet_identifier::text, $id::text, $locked_until::text))) > 0 THEN | ||
| error('a grant with the same grantee, original_credential_id, and locked_until already exists') | ||
| END; | ||
| $dwg_result = idos.dwg_veryfy_owner($dwg_owner, @caller, $dwg_id, $dwg_not_before, $dwg_not_after, $dwg_signature); |
There was a problem hiding this comment.
I would not assume that the caller is the grantee. I'd say that anybody can transmit this transaction (to enable flows where the IdV is the one integrating idOS, like in Fractal's case).
There was a problem hiding this comment.
Hmm, you are right. I will fix it.
There was a problem hiding this comment.
Changed by this 6d717dd
schema.development.kf
Outdated
| get_write_grant_id($user_id)::text | ||
| @caller, | ||
| $copy_credential_id, | ||
| 0, |
There was a problem hiding this comment.
Timelock should be part of the message, if I recall correctly.
There was a problem hiding this comment.
I was guided by this
ONE Access Grant for the Issuer that has NO Timelock.
So is this needed to ask timelock in the message and then not to use?
There was a problem hiding this comment.
I'm pretty sure that was a decision born out of trying to make things simple. Since adding the timelock to our current implementation is trivial, I argue that we should add it.
Let's disambiguate with Martin.
There was a problem hiding this comment.
…ture/write_grant_atomic
…o consumed_write_grants
Task
https://www.notion.so/idos-association/Write-Grant-per-atomic-Issuance-15788c585fe080a1833edf8e39505492?pvs=4
Changes in API
TBD
How do you know this works?
TBD
TODO