Closed mrcbond88 closed 2 years ago
Working through Timo's endpoints, tests and create pubDID to see which ones are outstanding and which ones are not working. From there once we've got our ducks in a row, we'll be a lot quicker to move through this.
Need to enforce the trust registry rules in the Cloud API.
issuer
.
Procedure for issuer. For each step if the verification fails abort the issuance:
issuer
Procedure for holder. For each step if the verification fails abort the issuance:
issuer
verifier
.
did:key
Procedure for verifier. For each step if the verification fails abort the proving:
did:key
, is registered in the trust registryverifier
Procedure for prover. For each step if the verification fails abort the proving:
connection_id
property)their_public_did
property), verify an actor is registered in the trust registry with the public DID of the connection -> prepend did:sov:
to ittheir_public_did
property), verify an actor is registered in the trust registry with the invitation key from the connection that, when transformed to a did:key
, is registered in the trust registry.invitation_key
property, transform it to did:key
(using ed25519_verkey_to_did_key
) and call the trust registry get actor by did endpoint.indy_pres_spec
requested_attributes
and requested_predicates
extract the cred_id
IF the value of revealed
is True.cred_id
from the previous step fetch the credential by id(/credential/{credential_id}
) and then extract the schema id from it.verifier
Very good overview!
Enforce the trust registry rules
* [Trust Registry Design](https://hackmd.io/8E6pYb4NRWKJy42tWt7BTA)
Need to enforce the trust registry rules in the Cloud API.
Issuance
* You can only issue a credential with a schema that is registered in the trust registry * You can only issue a credential if the actor is registered in the trust registry with the DID and with role `issuer`. * Should we DID that is registered in the trust registry
What does
Should we DID that is registered in the trust registry
mean?Issuer
Procedure for issuer. For each step if the verification fails abort the issuance:
1. Verify that the ACA-Py agent has a public DID 2. Verify an actor is registered in the trust registry with the public DID of the ACA-Py agent 3. Verify the actor includes the role `issuer` 4. Verify the schema id is registered in the trust registry
I suppose we can right a validator for all of this that extracts the required params such as actor_id schema_id from cloudapi input and checks against the registry. Then just call that validator in the process.
Holder
Procedure for holder. For each step if the verification fails abort the issuance:
1. Verify an actor is registered in the trust registry with the DID of the credential 2. Verify the actor includes the role `issuer` 3. Verify the schema id is registered in the trust registry
Same here, cumbersome - I agree - but once written can be made available anywhere in the code.
Verification
Requirements
* You can only request a proof for schemas that are registered in the trust registry * You can only request a proof if the actor is registered in the trust registry (how can we check this?) with the role `verifier`.
Also corollary to the above suggestion.
Another way is to extend the registry to not only provide a list of actors and then filter that etc. It could also have endpoints itself that answer these questions. So for given actor_id it returns is registered, is verifier...
* If the actor has a public DID we can check for the public did
I already added a did field (default None though).
- Extract the DID from the invitation? This could also be a mechanism within the trustregistry instead of the cloudapi.
- The DID from the invitation will be used for the invitation, but then another key will be used. So we would need to have the key from the invitation to make sure this is a valid request.
Verifier
Procedure for verifier. For each step if the verification fails abort the proving:
1. Check whether the ACA-Py agent has a public DID
Not 100% sure here but I was under the impression that the agents will all have a public DID in the YOMA case at least? That would make this check superfluous.
* If the ACA-Py agent has a public DID verify an actor is registered in the trust registry with the public DID of the ACA-Py agent * If the ACA-Py agent has no public DID verify a multi-use invitation exists in the registry that matches one of the keys in ACA-Py -> this makes no sense
Not sure I can fully follow here 🧐
2. Verify the actor (from step 1) includes the role `verifier` 3. Verify the schema id(s) used for the proof request are registered in the trust registry
Again 2. and 3. could be a generic validator (eg fucntion/class) within cloudapi. Or we extend the trust registry functionality to provide convenient answers.
Prover
Procedure for prover. For each step if the verification fails abort the proving:
1. Verify an actor is registered in the the trust registry * If the connection is made with a public DID, verify an actor is registered in the trust registry with the public DID of the connection * If the connection is not made with a public DID, verify an actor is registered in the trust registry with a multi use invitation of which the recipient key is the same as the invitation key of the connection 2. Verify the actor (from step 1) includes the role `verifier` 3. Verify the schema id(s) of the proof request are registered in the trust registry * Maybe we should verify the credentials that the prover is going to share, as the proof request could be loosely defined (but do we want to allow loosely defined proof requests)
Also question mark for me - not sure here.
The process of verifying whether a verifier is registered as actor in the trust registry can be quite cumbersome if a multi use invitation is used. All invitations in the trust registry must be decoded and checked if the invitation key matches the invitation key from the connection record. I think we should also define the
did
parameter in the trust registry for verifier without a public DID and somehow indicate this is not a public DID. This will make the verification process a lot easier.
I already put a did param (that defaults to None) into the actors model. Not sure hwo best to indicate when it is not a public DID. Any suggestions? I guess we could here as well do this in the trustregistry and automatically do the decoding of multiuse invitations and store the did in the did field?!?
Cloud API Roles
Current roles in Cloud API:
* member -> Multitenant agent * member * member_admin * ecosystem -> Multitenant agent * ecosystem * ecosystem_admin * yoma -> Agent * yoma
Very thorough and thoughtful of you @TimoGlastra 👍. Let me know what you think and hope this helps already. Whatever you/we agree on doing here eventually, we can also split up and I could for instance do some additions to the trustregistry if required.
What does Should we DID that is registered in the trust registry mean?
Lol that's not english! I think some left over comment.
Not 100% sure here but I was under the impression that the agents will all have a public DID in the YOMA case at least? That would make this check superfluous.
AFAIK we're not doing that because we then need to pay for a public DID for all verifiers which we don't want to do. @lohanspies any thoughts?
Not sure I can fully follow here 🧐
We need to check whether a verifier is registered in the trust regsitry. If we have the public did that's easy, but otherwise we need to extract it from the invitation. But as you said we should probably also set the DID in the registry for non public DIDs and somehow indicate whether it is public.
I already put a did param (that defaults to None) into the actors model. Not sure hwo best to indicate when it is not a public DID. Any suggestions? I guess we could here as well do this in the trustregistry and automatically do the decoding of multiuse invitations and store the did in the did field?!?
I think this has some limitations, or issues because the DID is not the same as the public key. And as the DID is not registered on the ledger we should be checking for the public key. So ideally we would use did:key
for the verifier DIDs as it is 'public' without needing a ledger.
Thinking of it, we could just use did:key
. We take the public key from the invitation, do some transformations and then store it as a did:key
.
If we can leverage ACA-Py as a dependency we can use the DIDKey
class from it. Otherwise we could write some of the transformations ourself (mostly base58 encoding / decoding)
TODO
Requirements
Required from API to spin up ecosystem partners: