Skip to content

WG 2022 05 02

Jump to bottom
Stephen Curran edited this page May 2, 2022 · 5 revisions

Agenda

Time: 7:00 Pacific (fixed), 16:00 CET

Zoom Link: https://us02web.zoom.us/j/85188125213?pwd=UHRUVlgweFJ0T0g4SVdDUytYSkxJUT09

Recording: https://youtu.be/1rrWbI9UDxk

Preliminaries

Main Agenda

  • Recently merged PRs
  • Open PRs Review
  • Discussion points from PR #40
    • How much of these details do we want to have within the AnonCreds (1.0) spec?
      • Discussion result -- we have to experiment a bit to really decide. Current guidance is to provide a pseudo-code walkthrough of the code with links to the source academic papers, and included where needed specific decisions made in AnonCreds that are left to the implementation in the academic papers. Volunteers agreed to do "generate creddef" and "verify proof" as examples.
    • We need to decide on where the terms "presentation" and "proof" should be used. Historically, AnonCreds has used "proof" for the complete "verifiable presentation" (the entire data structure), whereas in the W3C world, there is a (capitalized) Verifiable Presentation data model, and the "proof" is the item in both the VC and VP data models that holds the signature(s) and signature(s) metadata.
      • Discussion result: In general, we'll use "presentation" and "proof" more or less interchangeably and to mean the entire data model of the "verifiable presentation", including all of the components within a single "present proof" message sent from the Holder to the Verifier -- claims data, proof of non-revocation, signatures, source credential metadata and so on. We will not use "proof" for the specific item of the verifiable presentation that is the signature and its metadata.
    • We need to decide where "AnonCreds" stops and the Indy implementation begins in this section. For example, is the collection of credentials that satisfy a proof request a part of the AnonCreds spec, or something that should be called out needs to be done, and left as an exercise for an implementer.
      • In general, we'll stop at defining the protocol interactions and data models exchanged between the participants -- e.g. between the issuer and holder on issuing, and between the holder and verifier when proving. As such, while the spec might call out the need to have a way to find one or more sets of credentials satisfy a proof request, the implementation details of how to find those credentials will not be in the spec. The "level of detail" will cover (in this case) only that the holder receives a proof request, and combines that with credentials that satisfy the proof request to a routine that uses the inputs to generate the proof.
      • Copying and describing the Indy AnonCreds implementation is not necessary, although where helpful, a permalink into a recent version of the code is permitted.

Action Items:

  • Stephen to test out the generation of Jens PR to see if there are issues with it.
  • Will to look at documenting the "Generate CredDef" to the right level.
  • Ale and Jens to look at documenting the "Verify Presentation" to the right level.

Recording and Notes

  • Notes:
    • IIW points of interest
    • Discussion points (above)
    • Embedding AnonCreds objects within DIDDocs (good idea or bad?). Note that we decided NOT to do that in the did:indy DID Method.
Clone this wiki locally