Interop has support for vc-authn-oidc

[OR13]

There was substantial discussion regarding support for vc-authn-oidc here: https://github.com/decentralized-identity/interop-project/issues/9

https://github.com/bcgov/vc-authn-oidc/tree/master/docs

@swcurran @dhh1128 @awoie

I'd like to continue the integration conversation on a clean ticket that is just about adding support for vc-authn-oidc

I recognize that SIOP by itself does not address the same use case, as @awoie noted on #9.

I'm wondering whether we can sketch out what using vc-authn-oidc would look like for interop project end to end on this thread.

[OR13]

Its my understanding that if vc-authn-oidc existed today, and supported the DID Methods used for interop, then we could make the issuer and verifier web servers RPs, and use an OP server which supported vc-authn-oidc, to issue id_tokens which included the correct claims.

I imagine this would look something like:

https://vc-authn-oidc.issuer.example.com/.well-known/openid-configuration https://issuer.example.com/education-dashboard https://verifier.example.com/student-discount

Various Identity Wallet Apps / Agents / Hubs which would need to support vc-authn-oidc in order to download / hold credentials.

Am I correct in assuming that the issuer web ui, and issuer authorization server are 2 web services that would probably be run by the same legal entity?

What am I missing here?

Can we establish a path to supporting this flow in addition to OIDC SIOP?

[tplooker]

@OR13 great work on progressing all of this discussion, I am currently away on holiday, but once I am back I intend to be more involved in this.

In regards to your observations above its important to highlight that the vc-authn-oidc project is strictly aimed at authentication using verifiable credentials leveraging open id connect. How credential issuance is achieved is out of scope.

I think this diagram potentially describes most simply the differences in the approach

vc-authn-oidc

+--------+                                   +--------+
|        |                                   |        |
|        |------(1) VC-AuthN OIDC Request--->|        |
|        |                                   |        |
|        |                                   |        |                        +--------+
|        |                                   |        |---(2) DIDComm VC-PR--->|        |
|   RP   |                                   |   OP/  |                        |  IW/   |
|        |                                   |Verifier|                        | Holder |
|        |                                   |        |<--(3) DIDComm VC-P ----|        |
|        |                                   |        |                        +--------+
|        |                                   |        |
|        |<-----(4) VC-AuthN OIDC Response---|        |
|        |                                   |        |
+--------+                                   +--------+

did-authn-SIOP

+--------+                                                                     +--------+
|        |                                                                     |        |
|        |---------------------(1) DID-Auth SIOP Request---------------------->|        |
|        |                                                                     |        |
|        |                                                                     |        |
|        |                                                                     |        |
|  RP/   |                                                                     |   IW/  |
|Verifier|                                                                     | Holder |
|        |                                                                     |        |
|        |                                                                     |        |
|        |                                                                     |        |
|        |<---------------------(2) DID-Auth SIOP Response---------------------|        |
|        |                                                                     |        |
+--------+                                                                     +--------+

Is it safe to assume we are considering using SIOP as a means to achieve credential exchange? If so I have quite a few outstanding questions but I will wait to ask them.

[tplooker]

In reference to what you spoke of above.

With vc-authn-oidc it would enable an easy way to get verifiable information from identity wallets into web apps.

Identity wallets would need to support DIDComm and the verifiable credential presentation protocol which is just two JSON messages a request and a response.

In regards to the auth server being run by the same entity as the web ui, because there is a trust relationship between the two parties (for example the web ui trusts the auth server really did challenge the user to present verifiable credentials and they were verified). Then yes for most implementations I would expect that to be the normal.

[OR13]

Thanks these diagrams really help. Sorry I was slow to understand it.

Because of the various identity wallets (who really need to speak up on issues), we wanted to split auth from credential exchange. We are not considering OIDC SIOP as a credential exchange solution, it does nothing but provide an id_token (with no additional claims).

Since we can't use vc-authn-oidc today (if i'm wrong lets get the working implementation linked asap).

We thought it would be less work to split authentication and credential exchange and try to solve authentication first (since it should be smaller).

Thats still the game plan, but I would love if we can figure out how to also support vc-authn-oidc in exactly they way it is intended to be used by bcgov, with support for other DID Methods, such as btrc, ethr, ion, elem, jolocom, etc...

Thats what I want to focus this ticket on.

I'm gonna rope in @awoie @pelle @christianlundkvist from UPort for the sake of getting concrete.

Lets assume there is a vc-authn-oidc server out there that is open to the internet.

Lets assume I just created an did:ethr:0x1231... did... It has no services registered.

When i visit: https://issuer.example.com/education-dashboard

I am prompted to login with vc-authn-oidc.

Since I am a brand new user, I don't have any vc's converted to claims on the id_token which I will use to authenticate.

As soon as I click a button on:

https://issuer.example.com/education-dashboard

I now need to receive a credential.

This means the the UPort Wallet needs to express how it should receive the credential, and the issuer (BTC-R) needs to know to make this vc available to the verifier / OP so that a claim can be attached to my id_token the next time I log in.

I believe a concrete implementation of vc-authn-oidc is forthcoming, assuming that it existed today, how you UPort use it?

[swcurran]

For vc-authn-oidc to be used by other DID Method/VC implementations (BTCR, uPort, etc.) there would have to be DIDComm support added to clients of those methods. Alternatively (and what we expect will be easier), an Aries agent could be extended to include support for DIDComm protocols that supported those VC methods. At minimum on the identity wallet/holder side, that would mean adding support for receiving a presentation request and returning a presentation. On the vc-authn-oidc, support for the reverse - generating an appropriate presentation request and verifying a proof.

The additional work on the Aries side we think is relatively contained, as Aries already provides lots of the plumbing - did:peer based communications, mechanisms for establishing connections, etc. With all the plumbing, the added protocols are constrained to just the request presentation/presentation/verification elements on top of the plumbing.

I don't see this as palatable to the interop-project at this time, if for no other reason than there is not support yet for the JS stack favored on this project. I'm totally fine with that. I am hoping that independent of this project, we do get another DID Method and VC model (or two!) implemented as DIDComm protocols as a proof of concept. There are working Aries server-side and mobile-based agents that could be used for this work, so I think it would be a relatively light lift to use those as the basis for adding the necessary DIDComm protocols to achieve interop.

[OR13]

Thanks! Its possible that members would contribute the JS stack, in order to support the interop project, if they have a clear idea of what that would entails.

It sounds like the next steps are to define the protocol interaction sufficient for an implementer to contribute or wait for a concrete description / demo of using Aries with other DID Methods.