Page History

...

Recording of Call:   20230206 AnonCreds Specification Working Group Call Recording.mp4

Notices: 

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

...

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

Steve McCown (Anonyome Labs) <smccown@anonyome.com>

Ariel Gentile (2060.io) <gentilester@gmail.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

...

Open Issue

• Issues to Discuss
  • Issue #137 added regarding further investigation into what happens to the issuance data flow nonce(s) by Belsy
    • No progress yet.
    – definition completed, to be added to the spec. Stephen Curran 
  • Issue #107 what happens to prover_did?  Decisions made:
    • Rename the item to entropy  
    • Update the spec and implementation (again) to make the item required from the holder
    • Describe how the item is combined with the rev_idx (if available) and hashed to produce the credential_context and put in the VC as m2 
    • m2 can be checked by the holder to ensure it is based the provided entropy value.
  • 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
• PRs for review and merging
  • Merged one of the two PRs in progress.
• Checkin: anoncreds-rs implementation progress, requests
  • NodeJs wrapper performance issue: https://github.com/hyperledger/aries-askar/issues/76
  • Discussion about what to do about wrappers, especially if there is a need to drop the napi-js library to overcome this issue.  Various options were discussed, and links provided:
    • UniFFI Library for Mozilla to generate wrappers.  Describe the interface in a DSL, and then generate the wrappers thereafter.

      • From Steve McCown : https://firefox-source-docs.mozilla.org/writing-rust-code/uniffi.html

      • From Stephen Curran : https://mozilla.github.io/uniffi-rs/Overview.html

      • From Steve McCown : Here’s a link to the “Uniffi” tutorials that I wrote.  There have been a few updates to the tool, since I wrote these, so they might need some updating themselves.  I’ll take a look at that…

        https://github.com/mccown/ffi-tutorials

      • From Ariel Gentile : Thanks for the link Steve! I'll check it out to see if we can give a try using it
      • From Timo Glastra : Yeah UniFFI looks interesting

    • State of React Native wrapper

      • From Timo Glastra : The RN wrappers are already done and working! https://github.com/hyperledger/anoncreds-rs/tree/main/wrappers/javascript/anoncreds-react-native

      • From Timo Glastra : As Ariel mentioned, It's written in C++ (so no Swift / Kotlin)

      • From Alex Andrei : https://www.npmjs.com/package/@hyperledger/anoncreds-react-native

      • From Timo Glastra : We use a new React Native JSI (JavaScript Interface) https://github.com/hyperledger/anoncreds-rs/blob/main/wrappers/javascript/anoncreds-react-native/cpp/anoncreds.cpp#L96-L122

    • C++ Wrappers – why and where?

      • From pasquale : For Ariel and Timo: do turboModules work also with Rust libs? Or just C++? Cause I see cpp files in the anoncreds wrapper

      • From Ariel Gentile : Yeah we need to add a CPP layer in the middle. That's what we tried to avoid in NodeJs by using the node-ffi-napi / ref-napi (whose advantage is exactly that)

      • From pasquale : Ok I see, you use C++ in order to write an adapter layer in one single language instead of creating two (one in java and one in swift), am I correct?

      • From Ariel Gentile : Yes!

      • From pasquale : Gotcha, thanks

• Discussion: Mike Lodder has proposed that a group start on "Next Gen" AnonCreds based on his this recorded presentation at out 2022-11-28 meeting
  • Interest in this – figure out way to do this.
• PRs for review and merging
• Checkin: anoncreds-rs implementation progress, requests
• • Stephen Curran to find times that work for Mike and propose times for the group.
• Discussion – having an intermediary collect presentations from holders and then share them with the final verifier.
  • Use Case:
    • A bus is visiting a secure site for which all visitors must present ID.
    • Site sends the bus operator a nonce.
    • The bus operator uses the nonce in a presentation request flow with each passenger.
    • Bus operator verifies all of the presentations.
    • The Bus operator forwards all of the presentations to the site for verification.
  • Questions:
    • Is there value in the use of the nonce in this way?
    • Does this alter the cryptography in any way?
    • Terms of use of the data received by the bus operator?
  • Discussion to be carried forward to next week.
  Open Discussion

Future Calls

To Dos:

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

...