10A/DID Comm/OpenID & VC Comparison / Sam, Torsten

Session 10A

DID Comm/OpenID & VC Comparison

Session Convener: Sam Current, Torsten Lodderstedt

Notes-taker(s): Neil Thomson (after photo)

Tags / links to resources / technology discussed, related to this session:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

OIDC/DIDComm throwdown

Sam Curran v Torsten L.

For the purpose of exchanging VCs.

Can from a discussion in Dublin about DIDComm and other communication channels.

Looking for feedback and questions of better understanding of both ODIC and DIDComm.

Really need the slides Sam Curran

Message example DIDComm V2

• Type of message - created from a message family then version and message within the family
• From, to, expiry time
• Message and attributes of the message

Both of parties have DIDs and DID Docs

• Each as an endpoint for DIDComm and what is supported : endpoint DIDCommMessaging
• Have routing keys, etc.

Information sufficient to send to the other party

If you don’t know the DID for the channel, Alice creates an invitation to Bob with the DID, etc. so they can interconnect

Receipt of a message can be delegated to a mediator (e.g., server) by the DID owner

Encryption to protect delivery target and the content.

Sender does not need to know about the mediation of the reciever

No concept of a session, but there is a thread (connected messages)

Peer DIDs do not need to be written to a ledger.

Can add your own protocol within a DIDComm channel without any dependencies other than to provide information to the recipient to know what protocol is being used.

DIDComm is not a broadcast tool - peer/peer - pushed out for future consideration

Torsten L

OpenID for Verifiable Credentials (OIDC 4)

Specifically designed version

Issuance - simple OAuth API - all OAuth 101

So for authN/authZ - can use any OAuth workflow.

Interface between issuer and wallet

Can use all the common VC cred formats.

Interaction model assumes credential user interacting with a wallet

Alice connects trough wallet via OIDC for VCs to Issuer, that authenticates the user and provides the VCs back to the wallet.

Verifier is a resource which you would use an auth token, which the service can then request those from the user’s wallet via RP requests. This includes different disclosure/presenations.

Can support within same device and across devices

OIDC and DIDComm - are comparing apples and oranges. They are both fruit (claims Sam Curran)

The interaction on VCs is determined by specific exchange information (including the keys used to sign the VC, type of VC and other VC specific parameters). This is how this version of OIDC is different that standard OAuth 2.X underlying ODIC.

The OIDC model does not have a preferred communication channel.

DIDComm supports presentation of VCs as you can add protocols within the DIDComm channel to do so. Otherwise DIDComm is just a secure communication protocol channel.

The DIDComm model allows establishing authN/authZ and then that is associated with the DID pair (the two parties), so you don’t need to re-auth for each message.

With DIDComm can map an LEI to a DID and as the LEI is public, the DID (may be) public as well, so it is possible to create a connection directly to an Issuer without needing a DID search or lookup service.

OIDC could use DIDComm as the communications channel vs. HTTP(s)

If the OIDC user provide includes a DID then one will be issued. However, in OIDC DIDs are not the mechanism for identifying the endpoints to communicate through. Set the point above on OIDC/https

DIDComm - the DIDS for communication are likely different that in asking for VCs that the DIDs involved are likely different (e.g,, DIDs strictly for the DIDComm channel are likely not the ones used for general online transaction. Channel DID vs Entity DID.

OIDC and DIDComm (and any protocol are both heavily dependent on (configuration) metadata

Assumption is the OIDC issuer can also be an authorization server (OIDC Server) or may just be a service (AuthN/Z with an other OIDC server)

Need common binding elements between OIDC and DIDComm to mix and match.

Multi-protocol future - yes. For bridging from new to old. For legacy or change resistant ecosystem backwards compatibility.

Reality - these are two different protocols for different purposes.