[Openid-specs-ab] [EXTERNAL] Re: Starting SIOP draft discussion

Sun May 24 15:47:17 UTC 2020

Hi Pam,

thanks for sharing this draft with us. It’s good to see convergence between the two camps.

I’ve got a couple of questions/comments: 
- The draft describes how to use a wallet to login into a DID-aware RP. In my opinion, this draft introduces a OIDC-based alternative to FIDO2/WebAuthn. What do you think is the advantage of using OIDC instead of WebAuthn for exposing this capability? Providing the RP with end-user claims along with the DID would be one compelling reason in my opinion. Are there any plans to extend the draft in that direction?
- As far as I understand the ultimate check of the ID Token signature is conducted using the key in the DID document. Why is there a need to convey the JWKS in sub_jwks. Is this “just” to conform to the SIOP spec? Just relying on the DID as user id would allow to benefit from the built-in key rollover capabilities of DIDs. 
- I think the request to the wallet could be relayed from one device to another device, which an attacker could utilise to trick the victim into releasing a valid ID token that the attacker then can use to impersonate the victim at the RP. The main reason for this vulnerability is use of the custom scheme in the redirect URI, which isn’t bound to a certain OP residing on a certain device. RPs residing on a “real” URL could prevent this, RPs using custom schemes on the way back cannot. 
- the draft recommends the form post mode for delivering the response to the RP (e.g. to prevent token leakage). I’m not a web browser expert, but I don’t see how an app-based wallet could perform a OIDC response_mode=form_post. Don’t such apps typically do a traditional redirect and the OS then kicks in and load the target in the system browser or activate another app? 

best regards,
Torsten.   

> On 22. May 2020, at 20:46, Pamela Dingle via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> Hey all, 
> 
> DIF has written a decentralized identity draft profile for OpenID Connect self-issued provider.   The draft link is below, it needs review by this community and I hope we can find a converged path where we either move that profile to OIDF for ratification or have some kind of formal liaison so that both communities can easily work together.  Please note, this draft was not developed in the blockchain vacuum, I believe various of you have been consulted over time so hopefully when you read this you will see this as a reasonable initial attempt.
> 
> The draft is here:  https://identity.foundation/did-siop/
> 
> I think both Nat and Mike have the cross-foundational experience to make a recommendation on a good path forward - perhaps a joint meeting to review?
> 
> Thanks,
> 
> Pam 
> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on behalf of George Fletcher via Openid-specs-ab <openid-specs-ab at lists.openid.net>
> Sent: Friday, May 22, 2020 11:26 AM
> To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
> Cc: George Fletcher <gffletch at aol.com>
> Subject: [EXTERNAL] Re: [Openid-specs-ab] Starting SIOP draft discussion
>  
> I don't have any direct comments to these points other than to say that the topic of spinning out the SIOP work into a new document and revising it came up in the OpenID Connect working group meeting this past Thursday.
> 
> Topics discussed included making the 'sub' claim not tied to the public key and possibly using a DID-like identifier. Or at least allowing a DID as the 'sub' claim for those wanting to use SIOP with self-sovereign identity use cases.
> 
> Personally, I'm in favor of making SIOP real for today's use cases :)
> 
> Thanks,
> George
> 
> On 5/21/20 4:25 AM, Nat Sakimura via Openid-specs-ab wrote:
>> Hi
>> 
>> I and Edmund have been discussing the additional SIOP requirements that
>> were agreed to made into an independent document a while ago.
>> 
>> Here is what I am thinking right now. Edmund has a draft for new
>> "Aggregation Endpoint" of the Claims Providers (CP) that I am hoping that
>> he can follow up with.
>> 
>> 
>> 
>> General Flow happens like this.
>> 
>> 1. On-Boarding of SIOP to CP
>> 1.1. Dynamic Client Registration of SIOP to CP
>> 1.2. User Authorizes general data access to SIOP.
>> 1.3. SIOP obtains the AT/RT.
>> 
>> 2. RP asking for a set of claims
>> 2.1. RP requests the SIOP for a set of claims
>> 2.2. SIOP creates the constrained claims request using AT and uid whose
>> value
>>      is the `sub` value that the SIOP uses against the RP and should be set
>> as
>> the `sub` value of the aggregation endpoint response (NEW)
>> 2.3. CP returns a JWS signed JWT that contains sub=value(uid) and other
>> requested claims in the payload.
>> 2.4. SIOP puts the JWT in the ID Token and responds to the RP.
>> 2.5. RP verifies that the `sub` value of the ID Token is equal to the `sub`
>> value in the CP minted JWT,  besides all the verification that is required
>> for ID Token.
>> 
>> Here are some of the Requirements that follows the above.
>> 
>> 1. CP MUST support OAuth Dynamic Client Registration.
>> 2. CP MUST support "aggregation endpoint" that is capable of returning
>> constrained JWT with sub=uid.
>> 
>> Discussion
>> 1. What should be the aud of the CP returned JWT?
>> 
>> Please chime into this thread.
>> Perhaps I should create an issue in the tracker...
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> 
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab