24B/ More Killer Whale Jello Salad...figuring out how credential exchange can harmonize.
More Killer Whale Jello Salad...Figuring Out How Credential Exchange Can Harmonize.
Thursday 24B
Convener: Kaliya Young, et al
Notes-taker(s): Kaliya Young
Tags for the session - technology discussed/ideas considered:
DIDComm, Verifiable Credential Exchange, Aries Protocol, Bloom Protocol, Presentation Exchange,
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
ReCap & Summary
Because what we need is interoperable - issuance - issue-> holder || holder -> verifier some conversation about SIOP - has not been the focus of the discussion.
Goal to create a bridge between
the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
Aries protocols run on top of DIDComm
If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
So can be tested with next SVIP - testing.
Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
Potentially quickly spinning up a working group at DIF - Decision was to nest within the Credentials and Claims group at DIF
Agenda Creation
Things on the Path:
Scope/Goals:
Specification good and complete
BBS+ enabled attestation that transit across issuer, holder, verifier using the rails (paved path) that are envisioned here.
Maximal adoption as soon as possible,
Proceed forward in a way - that doesn’t require us to abandon some aspect of what we are doing - start with simpler form to get to bigger. Path can be made wider in future.
System architecture diagram that articulates how it all fits together - next step.
Do not re-invent things that already exist.
Test Suite - Test conformance vs. a Specification <- end goal interoperable implementation
A matrix Testing N-N testing - plugfest.
Be nice pick fast resolving DID methods for testing
Implementation Guide - maybe by: Documentation Corps in DIF
Test are about SHOWING the protocols work - not that the DID resolution works
Define the Rails:
Government issues the credential using software of their choice - did anchored in some did utility - citizen able to use a wallet of their choice - that they hold it in - business using a different software (and different ledger for their public did) all able to do this making their own choices. The reason they can is because of those rails - claim we can do this to a great extent - what we can not do right now across the linked-data signature Aries Ecosystem. Show how we can do what you just described across ecosystems. (Mediation is important - how do we do mediation on these rails).
System creating presentation is - web wallet, backend system or mobile app.
We need to handle working with registered web wallets - and also be able to formulate a payload for mobile (QR code) both of these paths need to be speced out to cover both communities.
We need as many Verifiers as possible (to devalue information on the dark web - with
Only HTTP Transport
Verifier - Holder - Issuer
Verifier - is a web accessible verifier.
Holder - app/mobile wallet, Browser wallet , backend service wallet (supply chain)
Issuer - is a web accessible verifier.
Things to Paint out of Interoperability Picture / Path Narrowing:
Non-HTTP Transports (however, let's leave room for non-HTTP transports for future iterations)
Don’t do negotiation in presentation exchange
Request -> Presentation -> Fail -> Error
Lots of way to specify requirements inside presentation exchange - features we decide we are not going to use.
Credential formats will comply with the W3C VC Data Model
Support for VC-JWT and LD Proof with example of BBS+ (BLS12381 G2) and ES256
No revocation (not ready enough yet) [revocation list 2020 does exist]
Holder refresh is out of scope [there is some work going on on this]
Issuer/verifier mobile app
Targets for path widening later
Revocation
Holder Refresh
Credential Issuance
What work will go where?
Work within DIF
Credentials and Claims working group (explicitly mentions something like "unifying existing formats and protocols" in its charter) <- fast time
Or new WG, draft charter by Balazs: https://docs.google.com/document/d/18L2-t4_2yrO_xZkwPjMCRcKIDiRGCziNs2X4k093pvo/
DIF - presentation exchange?
Timeline:
When is the next Claims and Credentials Group? (who are the chairs? - Martin, Wayne, Daniel McGrogan ) Bi-Weekly -
Work Items within DIF WG can have their own dedicated Calls.
Join DIF: https://identity.foundation/join/
Stewardship - , Orie, Brent, Snorre, Stephen? Troy
DIDComm Expert - Sam, Stephen
Presentation Exchange Expert -
Register for the first meeting:(26th April, Monday 1pm ET) forms.gle/SqkymupnYc9tDARm9
When do we want it done?
Good Health Pass has tremendous pressure!
When do we need what by?
Feedback into this group from Good Health Pass.
May 1: GHP Drafting Groups First Drafts Due -
June 1 GHP Interoperability Blueprint Recommendations Spec complete30 day vision
90 day vision <- would be ideal to have something that can be tested against for this timeframe.
180 day vision
July 1 Test Complete
August 1 - 10+ Implementations / Vendors passing VP Exchange Interop Tests.
October 1 - Cross Wallet Interop Exchange Tests.
Share with DIF Interoperability Working Group
Success Criteria:
Interop Testing Outcome
Artifacts Produced
Test Artifacts to TEST <- effort time and energy
Milestones:
Daniel Hardman wrote this before IIW in the DIF slack and many people +1 it.
this was ideated by Daniel before the last meeting, Balazs just copied it here for safekeeping.
I see this as being a layered spec:
Layer 1 = plaintext JSON payloads, presented in sequence, with possible error conditions. Understanding the spec at this level requires nothing except knowledge of JSON and the general problem domain of VCs. No DIDComm, no HL anything, no dependencies anywhere.
Layer 2 = Security. How to wrap layer 1 such that two parties can exchange the payloads and achieve the trust they need in the process. Here, I see a forked path: use TLS (in which case security is really simple, but is transport dependent), or use DIDComm (in which case you use the JWE wrapper that DIDComm is standardizing, based on keys in a DID doc -- more complex but more flexible). The key thing about Layer 2 is that once it's stripped away (e.g., by an adapter), the payloads exchanged at layer 1 are identical and interoperable.
Layer 3: routing. This is for delivering payloads via intermediaries. It is not needed by HTTP that's direct point-to-point. If you add this layer, you introduce more DIDComm-isms but gain extra flexibility as well.
If you like this framing, then I see a spec where layer 1 is presented very quickly and easily; it should be ultra simple and easy to understand by anyone who knows JSON. No mention of any dependencies anywhere.
This would be followed by an explanation of why additional layers could be added, and then a presentation of a 2-forked road, where one is pure HTTP (TLS for security, no routing), and one is DIDComm (DID docs for security, transport-independent routing). Both use the same layer 1.
Having presented the two forks at a high level, I would then imagine a page of text describing how the HTTP fork would work (HTTP status codes, adaptation for web sockets vs. web hooks, etc).
Then I would imagine a page describing how the DIDComm fork would work -- but instead of hyperlinking to DIDComm auxiliary material, it would be a page or two of copy-pasted material that would allow DIDComm compatibility without consuming any other docs.
The upshot would be a single doc that:
A) describes a simple exchange of messages that lets credential-based proof be requested and presented
B) Structures the messages in a way that's compatible with DIDComm, without requiring anybody outside the DIDComm circle to know that.
C) Explains how the protocol could run over a web service.
D) Explains how the protocol could run over DIDComm -- but in a simplified, self-contained doc rather than with dependencies.
E) Explains the tradeoffs of the pure HTTP vs. DIDComm approaches.
