[Openid-specs-mobile-profile] Review comments on openid-client-initiated-backchannel-authentication-core-01

Manger, James James.H.Manger at team.telstra.com
Tue Feb 5 06:21:13 UTC 2019


Comments prefixed with JM:

--
James Manger

-----Original Message-----
From: Openid-specs-mobile-profile <openid-specs-mobile-profile-bounces at lists.openid.net> On Behalf Of Torsten Lodderstedt
Sent: Monday, 4 February 2019 3:01 AM
...
- Section 4

-- Poll and Ping Modes with Pairwise Identifiers


— The second paragraph describes the way to ensure the RP is entitled to obtain PPIDs for a certain sector identifier. I see two drawbacks:

1) only the host component of the URIs involved is used to check for equality. This means RP’s residing on the same host in a shared environment automatically share the same sector identifier even if they are good citizens and use different sector identifier URIs. This is basically an issue of the OpenID Connect Core spec.


JM: Two RPs on the same origin aren't that separate; browser same-origin rules, for instance, will not firewall them from each other.
JM: The main reason to use the host component, not the full sector_identifier_uri, is so an RP that starts with 1 redirect_uri for 1 app then only later realizes they need to add a sector_identifier_uri to support more apps, can do so without breaking existing PPIDs.


2) The comparison of the host component of the JWKS URI and the sector identifier URI should work but to me seems like a workaround and imposes restrictions on the way RP construct URIs. Have you considered to put the respective JWKS URIs in the sector identifier JSON document? The syntax would need to be extended (as it is a simple JSON array right know). But this document serves a similar purpose for RPs than the openid-configuration file for OPs. So putting more metadata into it seems like a reasonable solution.  


JM: Putting jwks_uri in the content of sector_identifier_uri is already explicitly mentioned (without new syntax as it's just another URI):
JM:
JM:      If a "sector_identifier_uri" is explicitly provided, then the "jwks_uri" must be included
JM:      in the list of URIs pointed to by the "sector_identifier_uri".


— The third paragraph specifies in rather weak language how the client shall demonstrate possession of the respective private keys. Moreover, the check is deferred to the actual use of the CIBA functions. In contrast, in case of standard OIDC the check whether a redirect_uri belongs to the authorized destinations for certain PPIDs is checked at registration time. Deferring the check to the CIBA use puts the respective RP record in kind of a middle state.


JM: I'm not sure this is any different. If an app registration specifies CIBA + jwks_uri + sector_id_uri then the OP can check at registration time that the sector_id_uri content lists jwks_uri. If no sector_id_uri is registered then use the host part of jwks_uri (just like using the host part of redirect_uri for non-CIBA "normal: OIDC).
JM: "Normal" OIDC with a redirect_uri need to demonstrate ownership of that URI in each login; just like the CIBA flows need to demonstrate ownership of jwks_uri in each login.


Have you considered to let the dynamic registration function of the OP perform the check? One could use one of the methods cited in the spec (mTLS or private_key_jwt) to conduct the proof. Such an approach would allow to conduct all the checks necessary in one place and a single action and either accept or refuse the registration. 


- section 14

— „The OP SHOULD ensure that the "backchannel_client_notification_endpoint" configured at registration time is in the administrative authority of the Client. Otherwise, the OP would post authentication results to the wrong Client. How this check is done is outside the scope of this specification."  

Any idea how the OP should fulfill this requirement? I haven't found a similar requirement on redirect URI handling in the OpenID Connect Core spec although the risk is the same. 

I think the notification endpoint could also be placed in the sector identifier URI (or shall we call it rp-openid-configuration :-)).


JM: The text already says to do this (in section 4):
JM:
JM:      In case a "sector_identifier_uri" is explicitly provided, then the
JM:      "backchannel_client_notification_endpoint" must be included in
JM:      the list of URIs pointed to by the "sector_identifier_uri".




More information about the Openid-specs-mobile-profile mailing list