[Openid-specs-ab] Starting SIOP draft discussion

[Torsten Lodderstedt]

Hi Nat, 

> On 21. May 2020, at 10:25, Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net> 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. 

Is there similarity to the ideas in this ticket? https://bitbucket.org/openid/ekyc-ida/issues/1185/just-requesting-minimum-set-of-claims-for 

> 
> Discussion 
> 1. What should be the aud of the CP returned JWT? 

I think it must (at least) contain the RP’s client id (see https://openid.net/specs/openid-connect-core-1_0.html#IDToken) otherwise the JWT could be replayed with other RPs. 

An interesting question might be how replay on different devices for the same RP can be prevented. The nonce could be sent all the way through to the CP and included in the JWT as well. But given the weaknesses around public clients discovered in the course of the latest OAuth 2.1/PKCE/nonce discussion on the OAuth list I’m not sure whether that’s the best option.  

Another aspect: As discussed in Miyazaki, the eKCY-IDA request syntax could be used to determine a suitable CP (e.g. depending on the trust framework the RP asks for). With eKYC-IDA revision -10 the response from the SIOP could also contain the same verified claims from different sources. I think it’s worth incorporating these ideas/features into the SIOP draft. 

best regards,
Torsten. 

> 
> Please chime into this thread. 
> Perhaps I should create an issue in the tracker... 
> 
> -- 
> Nat Sakimura
> NAT.Consulting LLC
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab