The goal is to do an initial implementation of the validation process flow, based on the details written in VS Agent v4 spec. This implementation is at VS Agent SDK level only, independent from VS Agent app instances.
Applicant side
The flow will start at the Applicant VS Agent, when a new permission event associated to agent's DID is received. At this point, VsAgent of the applicant must allow the start of a validation process, which receives as inputs some basic info:
- Validator Perm ID
- Claims for the credential: initially we are focused on Org or Persona ECS schemas, but defined like this, it can be actually used for any schema
Then, VsAgent will internally query indexer to check that the specified Perm ID is active, and retrieve validator DID from its data.
Now it will be ready to start the vt-flow DIDComm protocol, sending the message to validator DID and passing to the validation-request message the holder permission ID, a random session UUID and the claims for the credential.
When validator processes the request and creates the credential offer (o rejects the request), it will receive DIDComm message events received from vt-flow protocol and should perform the corresponding checks (such as verify validator + digest) and update vt-flow record state.
Another VsAgent public API methods must be added to manually continue the flow (e.g. accept credential), after it should update vt-flow record state and send DIDComm messages/update Linked VPs on its DID Document as needed.
Validator side
Validator agent will receive the validation_request, and wil have a VsAgent public API method (to be defined) that sets it as validated (executes set-perm-vp-validated + calls corresponding vt-flow DIDComm module API method). At this point it will generate the credential (following the sign + compute digest procedure), execute createOrUpdate PermissionSession and finally send the Credential Offer through DIDComm.
It will handle further DIDComm events to determine when the credential has been accepted and therefore update the vt-flow record internal state.
Notes
- This is the initial, minimum implementation where we expect that all "optional" steps of the sequence diagram are not needed. But in the implementation it would be nice to consider that they might be added later.
- At the moment, neither of the agents is going to perform the VS-CONN-VS checks to resolve trust. This will be added as a further issue
- Since we are focusing on the basic implementation, we can implement this with the current VS Agent status as is. So we can do it using DIDComm V1 and implicit invitations.
The goal is to do an initial implementation of the validation process flow, based on the details written in VS Agent v4 spec. This implementation is at VS Agent SDK level only, independent from VS Agent app instances.
Applicant side
The flow will start at the Applicant VS Agent, when a new permission event associated to agent's DID is received. At this point, VsAgent of the applicant must allow the start of a validation process, which receives as inputs some basic info:
Then, VsAgent will internally query indexer to check that the specified Perm ID is active, and retrieve validator DID from its data.
Now it will be ready to start the vt-flow DIDComm protocol, sending the message to validator DID and passing to the
validation-requestmessage the holder permission ID, a random session UUID and the claims for the credential.When validator processes the request and creates the credential offer (o rejects the request), it will receive DIDComm message events received from vt-flow protocol and should perform the corresponding checks (such as verify validator + digest) and update vt-flow record state.
Another VsAgent public API methods must be added to manually continue the flow (e.g. accept credential), after it should update vt-flow record state and send DIDComm messages/update Linked VPs on its DID Document as needed.
Validator side
Validator agent will receive the
validation_request, and wil have a VsAgent public API method (to be defined) that sets it as validated (executes set-perm-vp-validated + calls corresponding vt-flow DIDComm module API method). At this point it will generate the credential (following the sign + compute digest procedure), execute createOrUpdate PermissionSession and finally send the Credential Offer through DIDComm.It will handle further DIDComm events to determine when the credential has been accepted and therefore update the vt-flow record internal state.
Notes