Christine Martin we will capture high-level requirements and tasks here.
The v1 protocol provides answers for three main questions
- Is this Issuer Authoritative to issue a particular credential type under a governance framework.
- Is a Verifier Authorized to request a presentation under a governance framework.
- Does the answering Trust Registry acknowledge another Trust Registry under a governance framework.
The analogy we have been using about the v1.0 protocol protocol is that it handles the simplest (but powerful) questions - it is the tip of the iceberg.
Key Areas to Consider for v2:
- Trust Registry Metadata - what data are needed by systems to understand a Trust Registry
- Credential Information/Metadata -
- Credential Names
- Credential Types - JWT, JSON-LD, AnonCreds, SD-JWT, etc.
- There are numerous flavours of VCs and much debate. This is a problem that Trust Registries can help. They can provide answers where there aren't any in the "we are compliant with W3C Verifiable Credentials" statement.
- Schema Definitions - provide the data or a pointer to the data (e.g. on ledger)
- Credential Definitions if required (AnonCreds requires) - provide the data or a pointer to the data
- Proof/Presentation Metadata
- What proof/presentation requests are supported and by whom can they be made? e.g. the overused driver license - who can request the full DL, versus an "age of majority" ZKP or some selective disclosure profile.
- What should be done for inappropriate requests - should they be reported?
- DID Metadata
- What DID Methods are supported
- What other expectations are at play (e.g. must support
did:method:identifier:GetCapabilities
or something similar.
- Wallet Metadata
- What wallets are approved (and how) in the ecosystem
- Holder Metadata
- A