Summary

Update on the AnonCreds V2.0 Working Group
Hyperledger AnonCreds Workshop – late May, early June
IIW Sessions – proposals, plans
PRs - just one
Issues to discuss -
Checkin: anoncreds-rs implementation progress, requests
Open Discussion

Recording of Call: dummyfile.txt

Notices:

This specification creating group operates under the Linux Foundation Community Specification License v1.0.

	Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct.

Meeting Attendees

Stephen Curran (BC Gov / Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>

Rodolfo Miranda (RootsID)<rodolfo.miranda@rootsid.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

Meeting Preliminaries:

Welcome and Introductions
Announcements:
Any updates to the Agenda?

Agenda

Open Issue

Update on the AnonCreds V2.0 Working Group
- Last week's meeting: Presentation Data Model proposals from Mike Lodder
- Next week: Revisiting the Issuance data models
Hyperledger AnonCreds Workshop - May 31
- Proposed Agenda:
  - Introduction to AnonCreds and ZKPs
    - Set Context – VCs, issuer-holder-verifier
    - AnonCreds
    - ZKPs overview
    - Where ZKPs are used in AnonCreds
    - Exercise – issuing, holding, requesting, presenting
    - Revocation
  - AnonCreds Methods
    - AnonCreds on other than Indy Ledgers
    - Ideally an exercise using AnonCreds with other than Indy
    - What changes when using other ledgers?
  - Making AnonCreds Credential Beautiful
    - AnonCreds and the Overlays Capture Architecture (OCA)
  - Future AnonCreds Features
    - AnonCreds in W3C Format
    - AnonCreds v2.0 — what’s next?
IIW
- AnonCreds Demos – working with Cardano, Cheqd, did:web?
PRs for review and merging
- There are is a backlog of issues to be applied to the AnonCreds spec – mostly assigned to Stephen Curran
- We have added a mentorship request for doing a pass through the spec to add all of the applications of cryptographic primitives
Issues to Discuss – None.
Checkin: anoncreds-rs implementation progress, requests
- Wrapping up wrappers, documentation
- Official release coming soon! Working in test deployments of Bifold
Open Discussion:

Future Calls

To Dos:

Issue #137 added regarding further investigation into what happens to the issuance data flow nonce(s) by Belsy – definition completed, to be added to the spec. Stephen Curran
Issue #140 should WQL be allowed in a Presentation Request?
- WQL is supported currently in the Indy SDK, but not in the Aries Frameworks
- Should it be in the specification?
- If so, in what form. From Sam Curren — don't call it WQL if we do include it – just describe it.
- Not used and it is not clear there is a good reason to support it.
- Complicates the specification and the implementation.
- Decision:
  - Not supported in the specification – let's keep it out in this version
Revocation Interval
- Approach to determine if the holder used an acceptable RevRegistry – see this Issue comment
- Who calls the AnonCreds method to get the Revocation Registry from the ledger for verification
  - Verifier ~~or AnonCreds?~~
- To set "validation" to true/false based on the RevRegEntry timestamp in relation to the revocation interval? Presentation
- Key points:
  - 1. an RevRegEntry is “current” from the time it is written, to the time of the next RevRegEntry
  - 2. “within the interval” is based on when a RevRegEntry is “current” (see 1.), not its timestamp.
  - 3. AnonCreds or the Verifier (calling AnonCreds) should calculate “within interval” (using 2.) and mark verification true if the RevRegEntry used by the Prover is within the interval, else false.
    - Dangers:
      - False-Negatives: If a strict "timestamp used is between from, to" and not based on when a RevReg is "current" (per 2.), we will get "not verified" incorrectly.
      - False-Positives: If we don't do any checking of the timestamp and the interval, the holder could incorrectly use an old RevRegEntry.
  - 4. General point: AnonCreds should return both a summary (true/false) and if false, additional data about why it was false.
- Decision – add an optional `at_from_ts` set of entries, one per NRP, that AnonCreds can use for determining if the holder_ts is within the Presentation Request interval.
Backwards Compatibility
- PRs in (#82, #105) that seem to change public data structures – ones that are handled outside of AnonCreds and/or by two or more participants (issuer, holder, verifier)
- We want to retain compatibility with existing data – credentials that have been issued and the published AnonCreds objects on which they rely.
- That extends to business logic – e.g. the handling of the objects not just by AnonCreds, AnonCreds Methods and Aries Frameworks, but also by business applications built on Aries.
- Suggestion:
  - Include in the specification a statement about backward compatibility
    - Perhaps this is what Ankur had planned to do?
  - Formalize what data structures will be expected by AnonCreds
    - This is being done throughout the specification and verified against the current implementation.
  - As needed support sending and receiving data in "old" and "new" formats, but (for now) always sending "old" formats.
    - TBD if there are any such cases.

Action items

Adding support for W3C Format AnonCreds to the anoncreds implementation and the spec.
Links to be referenced in the spec and used where needed:
- From Will Abramson : https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.186.5994&rep=rep1&type=pdf
- From Will Abramson : https://github.com/hyperledger/indy-hipe/blob/c761c583b1e01c1e9d3ceda2b03b35336fdc8cc1/text/anoncreds-protocol/README.md

Browser not supported