101 Session: Verifiable Credential Handler (CHAPI) and DIDComm
101 Session: Verifiable Credential Handler (CHAPI) & DIDComm
Convener: Manu Sporny, Orie Steele, Sam Curran
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Video Recording: http://vimeo.com/413742210 PW: weCOULDN'TchangeTHEname (note the apostrophe)
CHAPI and DID Comm 101 presentations were first
CHAPI 101 General: Connectivity between issuer, holder, and verifier
- “Dumb pipe”, open the communication channel
- CHAPI solves for the browser security model
- Problem statement
- How do you enable communication between App and web browser?
- How do you enable communication between different tabs in a web browser?
- Enable two websites to communicate between each other in a web browser
- Browser can create real time pipeline between two browser tabs (client to client edge communication)
- Problem statement
CHAPI allows to move data between two websites without leaving the machine
CHAPI doesn’t care about the content of the pipes Has a path that can grow into “WRAPI”—Web Request API—that lets any two websites talk privately via the browser
- Question about REST API - there is not one in CHAPI by itself
But in the DHS (US Department of Homeland Security) intro project the HTTP APIs and CHAPI APIs are both in use and therefore may seem intertwined
Q&A - Some requests for more explicit definitions:
- From the charter of the DIDComm WG at DIF: “Produce one or more high-quality specs that embody a method (“DIDComm”) for secure, private and (where applicable) authenticated message-based communication, where trust is rooted in DIDs and depends on the messages themselves, not on the external properties of the transport(s) used. The method must be usable over many means of transport, including those that are asynchronous and simplex, and ones that do not necessarily use the internet. It must support routing and relay through untrusted intermediaries, not just point-to-point delivery. In addition to the communication and protocols described above, the protocols for exchanging DIDs/keys to bootstrap such communication are within scope. These protocols can be the foundation of higher-level protocols such as credential exchange and higher-level authentication protocols.”
DIDComm in layman’s terms: http://www.windley.com/archives/2019/06/did_messaging_a_batphone_for_everyone.shtml
From Geovane Fedrecheski and Oliver Terbu, in the chat: “DIDComm is a standard way to exchange DID-aware encrypted messages, regardless of transport (e.g., unlike TLS, which is limited to TCP) - a set of subprotocols and related messages, such as those used for credentials exchange”
Sam Curren: explicit ACKs allowed (but not forced at this level), threading (see RFC )
Manu presented this slide:
The fact that CHAPI is named CHAPI is misleading, because its not just about VC exchange
Manu explained that the name Credential Handler API is so called because the browser vendors called their API the “Credential API”.
Highlights from Zoom CHAT during Deep Dive
From Dmitri Zagidulin to Everyone: 08:58 PM (quick reminder) CHAPI the protocol and the presentation queries used over chapi are separate - https://digitalbazaar.github.io/vp-request-spec/
From Michael Jones to Everyone: 08:57 PM Are you wanting to standardize any additional JWS and/or JWE algorithms?
- Orie: @MikeJones AFAIK they want to reserve terms like JWT did but for messages, thats why JWM is a thing.
Distinction b/w CHAPI and presentation-request spec? http://digitalbazaar.github.io/vp-request-spec/
- Orie Steele: http://github.com/decentralized-identity/presentation-exchange is not used by CHAPI… but could be used by DIDComm and CHAPI ; Correct… but I attend [to?] both and try to keep them in sync.
- Dmitri Zangadulin: the Peer to Peer section of the spec even mentions DIDComm; we’d love suggestions of how the two could work together
Commentary on Browser-vendor relations and W3C group (Wendell Baker’s backstory)
- Wendell: Here is the G thinking http://github.com/samuelgoto/WebID
- Tobias Looker: Yeap this ^ is essentially native support for the OIDC flow
Chat log PLEASE NOTE: POOR CHRISTOPH MENZER HAD HIS IDENTITY STOLEN by the “log in as host” button. all slanderous and reckless comments attributed to him in the log were actually made by notorious identity thief Juan Caballero