Versions Compared

Old Version 2

changes.mady.by.user Stephen Curran

Saved on

compared with

New Version 3

changes.mady.by.user Stephen Curran

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Summary

...

Summary

Excerpt
  • Update on the AnonCreds V2.0 Working Group
  • Hyperledger AnonCreds Workshop – May 31, 2023 8:00 Pacific / 17:00 Central Europe
  • IIW Recap
  • Discussion: AnonCreds in W3C VC and JWT formats
  • Checkin: anoncreds-rs implementation progress, requests
  • Open Discussion

Recording of Call

...

: 20230424 AnonCreds Specification Working Group.mp4


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>

...

  • Welcome and Introductions
  • Announcements:
    • Presentation at VC-API Working Group
  • Any updates to the Agenda?

...

  • Update on the AnonCreds V2.0 Working Group
    • Previous Meeting: ALLOSAUR Revocation
    • 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
    • Revocation
    • OCA
    • AnonCreds AMA
    • Lots of OpenID4VCs
    • OWF presence but no new information
  • Discussion: AnonCreds in W3C VC and JWT format
    • Importance? ?
      • Open discussion
        • Issue date / validity date
      • Verifiable Credential - Data Model 2.0
        • Research needed: What changes from 1.0, 1.1 to 2.0?
        • @vocab usage
    • Anyone know about the W3C to JWT transformation mechanism? JWT transformation mechanism?
    • AnonCreds RS:
      • Consuming a credential/presentation in another format should be easy
        • Sniff the format and convert to "internal" format.
          • Receipt of Credential
          • Receipt of Presentation
      • Production of Credential/Presentation in different formats?
        • Add a parameter to indicate the type?
        • Add a call to convert the type?
        • Produce multiple
        formats?
        • formats?
      • Revocation – how to manage?
        • Not StatusList2021, how to use the "W3C Format StatusList"
    • Other questions from Discord:
      • The process of issuance in this context, more specifically, what does a AnonCreds credential request would look like in w3c format. Is the AnonCreds in W3C VC formats feature only limited to a representation of the already signed and issued credential?
      • To sign a json-ld VC you apply a signature to the Credential, transforming it into a VC without a need to communicate with the holder. With AnonCreds there is an exchange between the issuer and holder to introduce the secret link before the credential is signed.to communicate with the holder. With AnonCreds there is an exchange between the issuer and holder to introduce the secret link before the credential is signed.
  • Demo: IDLab AnonCreds Flows demo–very cool!
  • PRs for review and merging
  • Issues to Discuss – None.
  • Checkin: anoncreds-rs implementation progress, requests
    • Wrapping up wrappers, documentation
    • Official release coming soon!  Working in test deployments of Bifold
    • Status of ASCA-Py implementation
  • Open Discussion:

...

  • 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.

...