101 Session: Verifiable Credential Handler (CHAPI) and DIDComm

101 Session: Verifiable Credential Handler (CHAPI) & DIDComm

Thursday 19A

Convener: Manu Sporny, Orie Steele, Sam Curran

Notes-taker(s):

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)

Slides: http://docs.google.com/presentation/d/1qPbwx9IXwPlgsZgS2XPXeGgstxrixnC8n0E2I4cxVc8/edit

CHAPI and DID Comm 101 presentations were first

CHAPI 101 General: Connectivity between issuer, holder, and verifier

CHAPI

“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?

Solution

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)

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

DIDCOMM 101

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”

Other Q&A

Sam Curren: explicit ACKs allowed (but not forced at this level), threading (see RFC [1])

Deep-dive

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