/
2024-02-19 AnonCreds Working Group Meeting -- Cancelled

2024-02-19 AnonCreds Working Group Meeting -- Cancelled

Mar 04, 2024

Summary

  • Meeting Cancelled – Holidays in the US and Canada

Time: 7:00 Pacific / 16:00 Central Europe
Call Link: https://zoom.us/j/97954159540?pwd=WWk3WmQ3MVh1SXBYZGVreGl0QllGdz09

Recording: 

Notices: 

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

cifi

Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

cifi

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>

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



Related Specifications and Repositories:

Meeting Preliminaries:

Agenda

  • AnonCreds in W3C Format - Status/Updates

  • Recent updates to AnonCreds RS – 0.2.0 release

    • When AnonCreds v1.0 1.0.0?

  • AnonCreds V2 ZKP Capabilities

    • Adding BBS+ to the library?

      • Extraction layer – abstracting other signatures, once done, adding BBS+ available.

    • Missing Object – revocation registry

      • Verifying key (96) and accumulator (48) – VK could be the identifier.

      • Definition - not needed

      • State - published on every accumulator update

    • How does Verifiable Encryption work?

      • Can be done by any party – need a BLS key pair - issuer, auditor, etc.

      • Issuer setup – anything? Encoding types?

        • Public key has to be published somewhere – most likely the CredDef,

        • A "message_generator" - point on the curve, like the public key – could use this to tie it down to a specific field.

      • Issue process

        • Nothing is done with VE at issuance time

        • Can be used with any claim

          • Could be used for specific values, e.g., Credit Card Number

          • But not defined apriori

          • Could use for a unique value – e.g. the revocation key

      • Verifier presentation request

        • Please give me a VE about a certain claim – reference to the two public data items (generator, pubkey), reference to attribute

      • Holder

        • Generates the encrypted value (verifiable cyphertext). Will be unique because of the nonce from the verifier.

      • Decryption process

        • Pass cyphertext (nonce, generator is embedded in cyphertext) to someone that knows the private key – decrypt to get the claim

    • Equality proofs – claims across two source verifiable credentials

      • Could be in the same credential 

      • Statement ID, List/Map of statement ID, claim ID.

      • Holder:

        • Creates a proof statement based on input of the claims

      • Verifier:

        • Verification of the proof and data

      • AnonCreds v1 aggregate – called "challenge" right now.

        • All of the proofs were generated by one holder

        • A signature over all of the proofs knew the raw data.

        • Not associated with the link secret in v1

          • In v1, there was an equality proof

        • Proofs that the data was fresh – e.g. used the same nonce in all of the proofs

          • In example – proof request ID is the nonce – everything is included in the aggregate proof signature.

    • Domain proofs (called a Commitment in V2) – consistent identifiers for a verifier – different across different verifiers

      • Issuer setup?

        • None

      • Issue process?

        • None

      • Verifier presentation request?

        • Creates two values – message and blinder generators - passed in the presentation request applied to a specific claim

        • Always use the same generators

      • Holder presentation process

        • Same as verifiable encryption – no decryption key

      • Verifier gets a consistent value from the holder

  • Question – call home for revocation

    • Does the issuer know who is calling home? No...

    • Trade-off – massive list, holder tells verifier which entry they are

    • Mitigate:

      • Get the latest state somehow.

      • Anonymous Revocation Handle Update - Call home – get me an update so I can proof a proof.

        • I have a credential.

        • Verifier to holder: Prove revoked as of this accumulator.

        • Holder to issuer: Give me an up to date witness for the accumulator – issuer does not know who is asking.

          • Holder – passes signature proof (I have a valid credential) – optional, accumulator, N shares of their element.

            • Issuer returns shares of the result. 

          • If revoked – not useful.

          • If never issued a credential – not useful.

  • Claim Schema format

    • Default encoding if no other information?  E.g. if just the name is given.

      • Dynamic encoding using AnonCreds v1 rules?  Notably: "If integer or integerString, then integer, else stringified and hashed"

    • link_secret automatically added as in AnonCreds v1?

    • Externalized set for list of set members

    • Date as ISO Date and encoded as Integer Date

    • DateTime as ISO Date and encoded as Unix Time

    • Research – what can be derived from JSON-LD information?

  • Open Discussion

To Dos:

Action items