...
Stephen Curran (BC Gov / Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>
Steve McCown (Anonyome Labs) <smccown@anonyome.com>
Related Repositories:
- AnonCreds Specification: https://hyperledger.github.io/anoncreds-spec/
- AnonCreds Methods Registry: https://hyperledger.github.io/anoncreds-methods-registry
- AnonCreds Rust Open Source Code: https://github.com/hyperledger/anoncreds-rs
- Ledger Agnostic AnonCreds Project Page: https://github.com/orgs/hyperledger/projects/16
...
- Update on the AnonCreds V2.0 Working Group
- Previous Meeting: Revisiting the Issuance data models – do we need an extra "attributes repository" object?
- Same objects as AnonCreds 1 – Schema, Credential Definition, Credential
- Schema adds types information on attributes – cryptographic types (string, numeric, scalar, enumeration, range)
- Proposed addition of new "Schema Claims" object that is effectively a "repository of claims" to be shared across schemas
- Name, type, validators defined at either the Schema Claims level or at the Schema level
- Next week: Presentation Data Models
- Previous Meeting: Revisiting the Issuance data models – do we need an extra "attributes repository" object?
- PRs for review and merging
- Issues to Discuss – None.
- Unrevealed Attributes, cryptographic vs. business-level verification, and related issues:
- Core issue – cryptographic verification vs. business purpose verification.
- Where does the AnonCreds specification end, and the Present Proof protocol take over?
- Clarification of the behaviour of unrevealed attributes. Based on recent message on Discord – gmulhearn
- Unrevealed attributes are the same as selective disclosure controlled by the holder.
- Unrevealed attributes are not (as I had thought) a way to choose to disclose/not disclose an entire referent (group of claims from a credential).
- This is a desirable feature: Being asked for multiple types of credentials (ORs), any of which are suitable, with the expectation the holder holds (will respond with) only one of them.
- Referents for "Person" Credential from three different jurisdictions (3 credential types), where any one person would ever only have 1 of the 3.
- The AnonCreds Presentation Request syntax has no mechanism to make this kind of request.
- Note: DIF Presentation Exchange does support this kind of syntax.
- This is a desirable feature: Being asked for multiple types of credentials (ORs), any of which are suitable, with the expectation the holder holds (will respond with) only one of them.
- In the "Ask for 3 when I only have 1" issue, the holder is (evidently) able act unilaterally, assuming what the verifier intended:
- A holder may respond to a presentation request with only a subset of the referents (claim groups) and the presentation will verify.
- The verifier must then decide what to do – accept the presentation as meeting the business need or not.
- E.g., ACA-Py was been coded to detect what the developer called a "bait and switch" by the holder – being very firm on the presentation matching the presentation request.
- However, this approach rejects both the use of "unrevealed attributes", and the "one of many" use case.
- E.g., ACA-Py was been coded to detect what the developer called a "bait and switch" by the holder – being very firm on the presentation matching the presentation request.
- Another example:
- Verifier presentation request asks for a "Proof of Degree" based on a common schema.
- The presentation may verify.
- Is the credential that was used for the presentation from a trusted source?
- Being able to scale requires this capability.
- Issue:
- AnonCreds stops at the cryptographic verification.
- The verification wrapper around AnonCreds verification may go further. Should that be part of the spec or not?
- The protocol around AnonCreds may or may not have a "business verification" response.
- How do we combine the two?
- For AnonCreds v1.0 we clarify what is possible.
- For AnonCreds v2.0 we adjust the design.
- AnonCreds stops at the cryptographic verification.
- To Do:
- Issue to talking about what AnonCreds verifies and what is left to the issuer to verify.
- Core issue – cryptographic verification vs. business purpose verification.
- Dynamic Accumulator Revocation scheme
- Proposal: To be presented two weeks from today.
- Checkin: anoncreds-rs implementation progress, requests
- Seems to be pretty stable right now – most effort is in using the implementation in various frameworks.
- Open Discussion:
Future Calls
...