DID AuthN for the Interop Project (due Aug 11th)

[awoie]

Please note that the DID AuthN review period will end by August 11th. The goal is to decide whether to use the SIOP spec in the course of the interop project.

The current proposal/ paper can be found here: https://github.com/decentralized-identity/papers/blob/master/did-authn/siop/did-authn-siop-profile.md

This will allow us to bring the decision to the next interop call.

If no substantial objections will be brought up and we can reach consensus, we will use the DID AuthN SIOP profile.

[OR13]

I strongly support this proposal, it would be a major milestone in interoperability just to implement this part, and because of the success of OIDC, this is the natural starting point for integrations with legacy systems.

[swcurran]

A few questions about this:

1. I don't see any reference to verifiable credentials in this and assume that is out of scope - e.g. that this is limited to DID authentication. Not raising this as issue but just to clarify the use case. Assuming that is the case, is there any thought to how verifiable credential authentication could be used? I'm guessing that would be a custom post-authentication flow by the RP?

2. It looks to me like this must use a publically resolvable DID, and hence, did:peer could not be used as the authenticated DID. Is that correct?

3. I think this does support the use case of the authenticating party creating a DID for every site for which they are using this kind of DID-Auth. On first visit, the user (via the Identity Wallet) would create a new DID (or would have a set of unused ones available) and authenticate with that. On subsequent accesses to the same site, they would use the same DID each time. Is that correct?

4. What needs to be implemented for this to work? Since as noted most OIDC clients don't implement SIOP, is the effort going to be take an existing OIDC client and add SIOP support? Again, not an issue - I'm just curious.

Thanks

On Mon, Aug 5, 2019 at 8:55 AM Orie Steele notifications@github.com wrote:

I strongly support this proposal, it would be a major milestone in interoperability just to implement this part, and because of the success of OIDC, this is the natural starting point for integrations with legacy systems.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/interop-project/issues/9?email_source=notifications&email_token=AAHYRQRTUBIEFJBYNDLPS7LQDBEOJA5CNFSM4IJMFQUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3SIIIA#issuecomment-518292512, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHYRQU5VT7CXDB5ZAA7YQTQDBEOJANCNFSM4IJMFQUA .

[awoie]

@swcurran these are great questions. See my answers/ comments below:

1. I don't see any reference to verifiable credentials in this and assume that is out of scope - e.g. that this is limited to DID authentication. Not raising this as issue but just to clarify the use case. Assuming that is the case, is there any thought to how verifiable credential authentication could be used? I'm guessing that would be a custom post-authentication flow by the RP?

Yes, for DID AuthN this was considered to be out-of-scope. But I guess, we have to address this for the interop project as well @OR13 ? While nobody would prevent people from using the flow to include self-attested claims (in the same fashion as OIDC) or W3C Verifiable Presentations in the id_token (OIDC Aggregated or Distributed Claims for W3C Verifiable Credentials might be considered for this), I'm personally in favour of defining a sub-protocol for credentials exchange for service endpoints. After the RP gets the <SIOP Response> and the DID Document, one could obtain the service endpoint and start the credentials flow. This should be done in the Claims and Credentials WG. Does this make sense?

2. It looks to me like this must use a publically resolvable DID, and hence, did:peer could not be used as the authenticated DID. Is that correct?

Please correct me if I was wrong, but as far as I understood, the did:peer requires to exchange the DID Document in the DID Exchange protocol. This is supported in the SIOP flow. We have a did_doc or did_comm claim in the <SIOP Response> to include the DID Document or potentially other information that is required. I recognized that there are some unintended gaps in the spec for non-public DIDs, e.g., no validation rules if the DID Document was included in the response; claim format of the DID Document in the response. If we addressed these gaps, would the spec work for peer DIDs?

3. I think this does support the use case of the authenticating party creating a DID for every site for which they are using this kind of DID-Auth. On first visit, the user (via the Identity Wallet) would create a new DID (or would have a set of unused ones available) and authenticate with that. On subsequent accesses to the same site, they would use the same DID each time. Is that correct?

Yes, that is correct. That should be fine, right?

4. What needs to be implemented for this to work? Since as noted most OIDC clients don't implement SIOP, is the effort going to be take an existing OIDC client and add SIOP support? Again, not an issue - I'm just curious.

It is a simple challenge/response protocol based on JWT. IMO, the implementation could be very slim. Indeed, the adoption of SIOP is not very big, as outlined in the "8 OIDC Considerations" section. I believe supporting OIDC makes sense and could help in increasing the adoption of SSI. Otherwise, we would have to fight slow adoption as OIDC had to do in the beginning. One strategy would be to convince OIDC RP providers like Auth0, or help/ contribute to OIDC RP implementation providers (e.g., https://www.npmjs.com/package/openid-client) to natively support that flow in their libraries.

[swcurran]

Thanks for the note, Oliver - much appreciated. We've had a number of discussions about this with Drummond (@talltree) in Victoria this week. A couple of thoughts to consider:

1. I recommend that the VC use case be thought through a bit. This is a necessary component for our use case (for our so called "Lawyer Use Case" we are building) and at this point, we think it's pretty hard to use SIOP with that without extending the RP to be a proper verifier, including the mapping of the verified claims into the OIDC token. If the VC handling is post-authn, then it again means putting a SSI agent capabilities into the RP. In that case, we prefer the idea of just using an OP that talks OIDC to the RP and DIDComm to the Identity Wallet.

2. We think there might be more than planned complexity in the use of a non-public DID. Specifically, either the key for the DID could not be rotated, or there would need to be support in the data exchange for rotating the key during an authn interaction. Without one of those, a third party finding out the DID (the string) being used could authenticate as the user with a different keypair.

[OR13]

@swcurran The VC Format is tracked here: https://github.com/decentralized-identity/interop-project/issues/5

It sounds like what we are both wanting is claims about an identity and some id_token for that identity, you are suggesting that it would be nicest if those claims came in the id_token.

Its 100% correct that if the OP attaches claims to an id_token they must verify them first, there is a standard interface for doing this in OpenID:

https://openid.net/specs/openid-connect-core-1_0.html#DistributedExample

However, SIOP only provides an id_token, and its probably not a good idea to try and add distributed claims to it without showing it working first.

With the id_token, an entity can be authenticated, and provide whatever credentials they want, in whatever format they want, JWTs, JSON-LD, etc.. the verifier will use the id_token to authenticate and the credentials to make authorization decisions.

In the future if SIOP supports Distributed Claims, perhaps these can be combined, but the claims would have to be in OIDC format.

This proposal is to provide an end to end implementation of SIOP for use with the interop project.

I want to unpack:

"In that case, we prefer the idea of just using an OP that talks OIDC to the RP and DIDComm to the Identity Wallet."

SIOP is for authenticating a DID, the use of the term identity wallet is again confusing things here.

I think what you are saying is that you want to exchange credentials with DIDComm. If thats the case, then this proposal will work for you, especially if SIOP does not support Distributed Claims.

If SIOP supported Distributed Claims and they were provided by DIDComm that sounds like your ideal solution.

I'd like to understand more about all the places that DIDComm could be used, can we get a ticket opened that tries to solve all the interop challenges with DIDComm? That would help me understand it a bit better.

[OR13]

@swcurran It sounds like you might have some valuable insight for this issue as well:

https://github.com/decentralized-identity/interop-project/issues/6

Especially about how DIDComm might be used to request credentials.

[swcurran]

@OR13 - I thought this group was using the term identity wallet, hence my use. What term is being used for the thingy that the user has that has the private keys of the DIDs and (optionally) the credentials? Anyway, that's what I meant.

I'm not sure of the relevance of the cited example. For distributed claims, it seems to be using a "call home" model where the claims from issuers are retrieved by contacting the issuer. That's a model we're not using.

Regard the comment I think what you are saying is that you want to exchange credentials with DIDComm. If thats the case, then this proposal will work for you, especially if SIOP does not support Distributed Claims.

I don't think that's right. What we want is an RP that ONLY talks OIDC to be able to use/trust verifiable credentials. Based on the examples we've seen, we think the best way to do that is to create an OP that talks to the RP using OIDC and talks to the Holder/Prover (the thing I don't know how to name) with DIDComm since that is it's intended purpose. That allows us to introduce verifiable credential based-authn/authz without changing the RP, other than to add configuration. The OP is where the verification of the VC occurs and so must be trusted by the RP - hence likely on the same infrastructure/controlled by the same entity (in our case, run on BC Gov HW/run by BCGov ops).

A question is whether this thread impacts the Interop Project and the use of SIOP. I'm guessing not, but for us SIOP is not great choice because isn't supported by the IAM vendors, and even if it was, it doesn't support VCs easily, and certainly not without extensions that will be hard for the OIDC community to move on (notably - being a verifier). We think that a dual-personality OP will get us further faster, and for the long term.

[OR13]

@swcurran I feel like we are saying the same thing :)

what we want is an RP that ONLY talks OIDC to be able to use/trust verifiable credentials.

We think that a dual-personality OP will get us further faster, and for the long term.

Does this mean you wish to obtain an id_token for a DID which contains VC, because the OP is a verifier?

Does DIDComm plan to integrate with OIDC? or extend it to support this functionality?

I think using the term RP but planning to not support OIDC is confusing me.

[OR13]

It seems like both OIDC SIOP and DIDComm are defining challenge response based protocols that rely on URIs and JWTs.

Here is a credential exchange spec for did comm: https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange

I propose the following:

• DIDComm and OIDC SIOP agree to an id_token only auth flow based on JWTs, URIs and QRCodes.
• We document how RP can leverage this id_token with VC.

In order to do this, we need to understand how DIDComm plans to handle auth, how it leverages existing authN technology, whether it supports JWTs, OIDC.

If most users of DIDComm prefer a custom id_token that is not OIDC compliant but contains VC and enables faster development, I think that is excellent, but for the purposes of the interop project we need to separate auth and credential exchange in order to support all the different member organization credential mgmt systems.... Hubs, Agent, Wallet Apps...

Put another way...

The interop issuer wants:

1. to authenticate DIDs
2. to deliver credentials to them.

depending on the services listed in the DID, the issuer should attempt to deliver credentials in different ways.

While its easy to support authenticated credential exchange if everyone agrees to a protocol for it, that seems harder to accomplish then splitting auth and delivery of credentials, especially if we want to support OIDC.

[swcurran]

Not sure where to take this convo, but this isn't working :-). Perhaps on a future call. Bottom line for us is that SIOP is not particularly helpful given the current state of IAM and the difficulty in using VCs in the authn process.

To clarify your confusion above (I think using the term RP but planning to not support OIDC is confusing me) - from the perspective of the RP, in the approach we are planning, the only protocol will be OIDC.

[dhh1128]

The core contract of OIDC is that the RP trusts the Provider to make assertions about the party that's trying to authenticate, on the Provider's own authority. When I login to a website with Google or Facebook, the website is trusting Google or Facebook to A) assert that I'm the legitimate owner of an identity they should trust; B) assert on their own authority attributes like my email address or name.

SIOP doesn't change this. However, it does change what are reasonable assertions for the provider to make, because the provider is now the same as the party being challenged--all assertions are now self-asserted, and what the provider asserts on their own authority is now suspect. It turns out that it's fine to self-assert that you control a DID, because this can be trivially proven. And it's fine to self-assert your email address, in many use cases. But it's not fine to self-assert that you have a valid passport or driver's license. Yes, those fact can be proved--but not with the simple token-granting mechanism that OIDC offers. To prove something complex like that, you'd have to tunnel sophisticated, possibly interactive exchanges of nonces, requests for proof, and offers to respond, through a channel that wasn't built for it. And unless the channel has cryptographic guarantees that are just as strong as the ones that created the credentials, you might degrade trust by doing so. Exchanging credential-based proof is a job for a different protocol, not for OIDC. Remember that the goal of OIDC--the very reason it was created--was to authenticate (produce a binary yes/no about whether someone matches identity), not to facilitate a rich give-and-take with nuances and a potentially large corpus of evidence flowing.

Now, in a use case where an institution has backend systems, and access to all of them is governed by LDAP or AD or something similar, it can make total sense to tackle the question, How could we use credentials to grant people access? A non-SIOP provider mediating between user and the institution makes sense here. Think about the dynamics: there's no risk involved in the institution trusting the OIDC Provider, because that provider is their own server. If they want to configure that server to engage in a super complex credential flow with the user, or a trivial one, they can--it's just a configuration and trust choice that they make. The provider is inside their own sovereign domain; they can therefore trust all of its assertions. The provider is free to base those assertions on the results of a sophisticated, DIDComm-based protocol that involves credential exchange with the user. But the relying parties don't care and don't need to know. They just need to ask the provider to do the right thing. I think this is @swcurran 's use case, and it makes total sense.

This doesn't work with SIOP, because there's no good way to do rich evidence exchange, and even if there were, the burden of evaluating that evidence would fall on the RP. The RP would have to "speak" credential format, revocation checking protocol, etc.

Bottom line for me: The SIOP approach is interesting. It solves a particular problem, if the standard for authentication is as simple as proving you control a DID. But if the standard for authentication involves proof with verifiable credentials, I think the other approach--where the Provider is a server run by the same org as the RP--is required. They solve different problems, and we shouldn't try to fit square pegs into round holes by conflating them.

@swcurran @tplooker

[tplooker]

@OR13, perhaps viewing this repo https://github.com/bcgov/vc-authn-oidc will provide more clarity to the approach we are taking with VC authn? As Daniel eloquently described above we are building an OP that supports vc authn over OIDC. So that existing RPs that are OIDC clients can just ask an OP that supports vc authn to use that as the method of authentication. The OP in this case acts as the verifier of credentials from a holder and uses didcomm as the messaging protocol to achieve communication with the holder. The OP then takes the information disclosed in the verifiable presentation and returns an ordinary id token back to the RP including the disclosed credential attributes as ordinary claims

[swcurran]

Thanks @dhh1128 - way better explanation than I was able to provide. A slight addition is that the simple case - prove DID ownership - is pretty easily done with the approach proposed in https://github.com/bcgov/vc-authn-oidc - although we might need to add a new DIDComm protocol.

[awoie]

@OR13 @swcurran @tplooker @dhh1128 I will try to compare these two approaches and IMO, both approaches serve a different purpose:

DID AuthN SIOP:

• Two parties involved, i.e., RP and SIOP (which is represented by some wallet/user)
• RP does not have to register with the SIOP
• Simple challenge/response flow
• SIOP does not have to be known to the RP because it uses a standard URL
• Backward compatibility with SIOP
• Focus is on proofing control of a DID
• Does NOT have to be integrated with every OP vendor, e.g., keycloak, forgerock, etc.
• RP requires additional business logic to cross-verify with DID Document if this is needed
• Low adoption of SIOP flow
• Focus is on public web applications, or mobile apps
• Scaling is quite easy as you rely on a static URL to your SIOP
• Nobody except the two parties can track/trace the user's behaviour

VC AuthN OIDC:

• At least three parties involved, i.e., RP, OP and some wallet (user)
• RP has to register with the OP (dynamic/static)
• VC AuthN is a simple challenge/response protocol integrated into the Authorization Code Flow
• OP URL has to be known to the RP
• Full backward compatibility with all OIDC flows
• Focus is on proofing of VCs
• Has to be integrated with every OP vendor using it, e.g., keycloak, forgerock. Note, OIDC does not have a standard extension point for the authentication step that automatically plugs into every OP. This is out-of-scope of the OIDC spec.
• RP does NOT have to implement additional business logic as it won't know any DID was involved at all.
• High adoption of Authorization Code Flow (in fact that is the only mandatory flow)
• Focus is on enterprise web applications, or existing federated IAM topologies
• Scaling in terms of integrating is harder but might not be needed -- you need an IAM Architect that sets up the federation between your RP and another OP. If you had 100s of OPs, you don't want to integrate them all in your mobile app.
• OP sees all the traffic and can potentially track/trace the user

[awoie]

To find a solution for the interop project, we need both: 1 DID AuthN 2 Exchanging VCs or presentations

I think we agreed that we want to decouple 1 from 2.

For 1, we could use SIOP. After doing the SIOP exercise and the conversations that we had, I think it could make sense to have a dedicated OAuth2/OIDC grant type for DID Auth, or even for exchanging the VCs. The new grant type could be very similar to SIOP but without the extra backward compatibility with SIOP, i.e., no sub_jwk required, iss does not have to be selfi-ssued.me etc.

Why even do the extra work of having OAuth2/OIDC? Existing web apps, PWAs, native apps use the Auth2/OIDC approach and respective libraries. Even Apple uses OIDC for their Apple login. Because Apple also mandates their login if multiple login modalities are provided (according to their terms of use -- more info here), we should make the life of the devs easier and contribute to OIDC/OAuth2 RP/client libs that are widely used.

The new grant type could even make use of aggregated claims or distributed claims to exchange the VCs -- e.g., distributed claims could point to the DID Comm service endpoint (hub/relay agent), aggregated claims could directly include the JWT VC.

[awoie]

@swcurran In case the above statements made a different impression, IMO the OP authN DID Comm integration that you are doing is very valuable. I would appreciate it if you could design the VC exchange part in a way that it supports all types of VCs (but I believe that is the intention).

[dhh1128]

@awoie I (strongly) agree with virtually everything you summarized. The only thing I would tweak is in your summary of the VC AuthN OIDC. You describe the RP and the OP as different parties. I agree that they are different servers, but I think they are very often owned by the same org. This is what makes it practical, in the use cases that that approach targets, to assume that the OP and RP are configured in mutually compatible ways, know one another's URIs, etc.

That small tweak has no impact on the larger analysis. I think the SIOP stuff is a great direction for this interop project, for all the reasons you've pointed out. We need both approaches, for different use cases.

[swcurran]

Nice job, @awoie! That captured things well. I'm not sure that the integration with IAMs is as challenging as it sounds in that list, but we'll let you know with an implementation.

The idea of the separation of Auth-DID/VC from VC presentation is interesting and we've been thinking about it as well. A big use case for us is using this approach to eliminate user ID/Password in Gov't with VCs across the 1000's of unchanged apps BC Gov operates. For that, the VC for authn/authz is sufficient.

However, as you and others have pointed out in this issue, a subset of those apps will transition to using VCs (and more generally, DIDComm) for non-authz purposes. For those apps, the connection handling is interesting. Do the apps use (or perhaps just bootstrap off) the auth-DID/VC mechanism, or do the apps establish their own connection directly with the user's component? It's an interesting question that we are exploring with this work. Again - implementing will help us learn.

[OR13]

The due date for this is past. I'm going to assume we have adopted DID AuthN with OIDC SIOP, and we can tackle credential exchange next.

[OR13]

I'm going to close this issue, and open an implementation ticket:

OIDC SIOP Implementation: https://github.com/decentralized-identity/interop-project/issues/14

Since there has been a lot of credential exchange discussion here, I'm going to open a new ticket regarding credential delivery post AuthN:

https://github.com/decentralized-identity/interop-project/issues/15

[OR13]

Lets continue the discussion for adding specific support for vc-authn-oidc here:

https://github.com/decentralized-identity/interop-project/issues/16