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 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
- Centralized / Decentralized - what does this question even mean?
- Credential Information/Metadata -
- Credential Names - how do we name these things?
- 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.
- The use of Credential Types in Trust Registries will answer the question of "what credential format are ACTUALLY used?"
- 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
- Other technical things
- Key Bindings
- DIDAuth - is DIDAuth (its real-world implementations)
- Service Discovery -
BACKGROUNDERS:
- Trust Continuum - Scott Perry's - Trust Decision...
- Trust Assurance Companion - https://trustoverip.org/wp-content/uploads/ToIP-Trust-Assurance-Companion-Guide-V1.0-2021-10-19.pdf
- Trust Assurance & Cerfification - https://trustoverip.org/wp-content/uploads/ToIP-Trust-Assurance-and-Certification-Controlled-Document-Template-V1.0-2021-10-19.pdf
2022-11-24
- Antti - connection is underlying
- TRs help create context for connection (and more)
3 Comments
Christine Martin
Antti Kettunen: New feature suggestion
The problem it’s solving is the discovery of trust task service providers (issuers, etc.) and pre-connecting the end-user’s wallet with the N-number of service providers that are registered as trusted entities in the trust registry.
Slide deck to explain the problem and propose a high-level solution: https://docs.google.com/presentation/d/1xGU8YWDgAqp8PCr9Um_3QQ1LT4NCt0y5c7u6GX4rQRw/edit#slide=id.p
Antti & Victor discussion: https://trustoverip.slack.com/archives/C024WE961F1/p1669133335428109
Christine Martin
Antti: I want to highlight the GCCN document on TRAIN approach to Trust Registries that Vitor shared in the long subthread we had above. I recommend reading from TR 2.0 spec perspective:
Darrell O'Donnell
please put Antti's slide deck reference, the slack thread, and the LFPH deck links in the Backgrounder section. Confluence hides comments when editing so you'll need two browser instances open.