Ecosystem management

[mrcbond88]

TODO

• Provision yoma agent after startup #190
• Do not register public dids for ecosystem partners as endorser #176
• [cloud-api] allow opportunity providers with role of issuer to write credential definitions using yoma as an endorser #159
• [cloud-api] integrate trust registry and ecosystem into tenant api #157
• wallet create public did do not return in did_object but on top level #186
• Do not register public dids for ecosystem partners as endorser #176
• remove usage of unprotected registration methods for von and staging net #185
• Integrate schema endpoint of cloudapi with trustregistry #141
• Provide details for partner by DID based on trustregistry #143
• Endpoint to register (an existing) DID on the ledger #144

Requirements

Required from API to spin up ecosystem partners:

• For issuers and verifiers
  • Create subwallet for ecosystem partners to be able to act as issuer, verifiers & members.
• For verifiers
  • Add verifiers to trust registry in the role of verifier with enough context to make establish connections with/from yoma members.
• For issuers
  - When a partner onboards as an issuer, Yoma will automatically write a public DID for them.
  - Provide schema list to ecosystem partners( as role of issuer). The endpoint exists and will call the schema list for partners to choose from.
  - Once schema is chosen, allow ecosystem subwallets to write to ledger via transaction endorser protocol. (Only credential definitions)
• For all
  • Enforce the trust registry rules

[mrcbond88]

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.

[TimoGlastra]

Enforce the trust registry rules

• Trust Registry Design

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

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

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

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 with the role verifier.
  • If the actor has a public DID we can check for the public did
  • Otherwise we can check for the invitation key against the did:key

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
   • 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 if the connection you want to send the proof request to has an invitation key that, when transformed to a did:key, is registered in the trust registry
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

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
   • Retrieve the connection that is associated with the presentation exchange (connection_id property)
   • If the connection is made with a public DID (has their_public_did property), verify an actor is registered in the trust registry with the public DID of the connection -> prepend did:sov: to it
   • If the connection is not made with a public DID (doesn't have their_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.
   • Take invitation_key property, transform it to did:key (using ed25519_verkey_to_did_key) and call the trust registry get actor by did endpoint.
   • if not connection id, we ignore the actor for now? -> Open new issue to solve that issue later on
2. Extract the schema ids from the indy_pres_spec
   • for each key value pair in requested_attributes and requested_predicates extract the cred_id IF the value of revealed is True.
   • For each unique extracted cred_id from the previous step fetch the credential by id(/credential/{credential_id}) and then extract the schema id from it.
3. Verify the schema ids are registered in the trust registry
4. Verify the actor (from step 1) includes the role verifier

[morrieinmaas]

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.

[TimoGlastra]

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.

[TimoGlastra]

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)