[Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text

Mon Jun 19 12:33:52 UTC 2017

That might be possible but at the moment no one is using a registration access token.

That has been more or less replaced by the software statement.  

However in CIBA polling you have no way to bind the software statement to the client.  
To do that you need to treat the software statement as secret.

We would also need to look at what happens when the client updates the software statement to say add a new redirect URI. 

What is the relationship between new and old so that the same siu can be specified?

For the GSMA it might be possible to say that the software statement must always include a SIU.  
Then we punt to some unspecified system to correlate registrations.

I don’t know how that would work in a generic spec?

Something like don’t allow CIBA polling unless the registration is done via a software statement from a federation operator that is verifying the SIU via some out of band mechanism.

That however doesn't get around the problem that we now have a bearer software statement that could be used by anyone.

John B.

> On Jun 19, 2017, at 5:25 AM, Axel.Nennker at telekom.de wrote:
> 
> Maybe we could define that the client who first used a sector_identifer_uri can use its Registration Access Token to register the next client that wants join the group of clients that use this SIU?
>  
> Axel
>  
> https://openid.net/specs/openid-connect-registration-1_0.html#Terminology <https://openid.net/specs/openid-connect-registration-1_0.html#Terminology>
>  
> From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
> Sent: Mittwoch, 14. Juni 2017 21:57
> To: Nennker, Axel <Axel.Nennker at telekom.de>
> Cc: James.H.Manger at team.telstra.com; openid-specs-mobile-profile at lists.openid.net
> Subject: Re: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text
>  
> inline.
>  
>  
> On Jun 14, 2017, at 2:16 PM, <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>> <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>> wrote:
>  
> Maybe the point we are talking past each other is that in front channel ONE client_id can have several redirect_uris which lead to different subs when NO sector_identifier_uri is defined while in back channel there are no redirect_uris and there is always a sector_identifier_uri?
>  
> Also two different clients can have the same SIU and generate the same PPID with different redirect URI, so as an example Google.com <http://google.com/> and Youtube.com <http://youtube.com/> could cave diffrent landing pages for redirect but generate the same PPID.  This is perhaps the main reason we added this,  otherwise we could have used the client_id directly to generate the PPID.
>  
> Perhaps you are thinking PPID are always different for different client_id.  They are not.   You could cave one client_id for CIBA and another for front channel and have both generate the same PPID via the SIU.
> 
>   
> So in OIDC (front channel) one legal entity can have one backend server and several mobile apps and in the redirect all apps use the same client_id but different redirect_uris which leads to different subs if no siu is defined and to the same sub if a siu is defined.
> Although I wonder why one legal entity might want different subs anyway…
>  
> They wouldn't that is why they would use the SIU perhaps it should have been mediatory in the base spec, but wasn't because it was argued that most clients have only one redirect_uri.   What IdP so to create a PPID without a sector identifier is unspecified and many may use the client_id causing a problem if the client_id is ever changed, or use the first registered redirect_uri (that can also cause things to break or be insecure)
>  
> At the time people didn’t think IdP would really use PPID so people were not that interested.
>  
> I can buy the argument that the core spec made a mistake not requiring a SIU if PPID are used.
> 
> 
>  
> And in OIDC one legal entity which has multiple clients with different client_ids would define a sector_identifier_uri to get the same sub for all clients.
>  
> Yes.
> 
> 
> In CIBA the same legal entity with multiple client_ids needs to define a siu to get the same sub or different sius (one for each client_id) if they want different subs.
>  
> Yes but they need to do it in a way that some other organization  can’t register there SIU and be able to correlate identifiers without permission.
> 
>  
> Although none of this has anything to do with validation of meta-data nor with jwks_uris…
>  
> The prevention of SIU hijacking is done in registration section 5
>  
> Adding the jwks_uri is one suggestion of a way to prevent SIU hijacking. 
>  
> The question is how can the AS correlate across multiple client_id.
>  
> Another possibility would be to make the client authenticate for registration in some way, 
> Perhaps the client creates a self signed software statement that contains the jwks_uri to validate the software_statement, and contains the SIU that also contains the jwks_uri.  That would prove the client registering is part of the same admin domain.  The client can then get a client_secret and client_id and use those at the authorization and token endpoints.
>  
> I am open to other ideas,  but something needs to securely correlate multiple clients using the same SIU and without a redirect or post back URI to check we need something else.
>  
> John B.
>  
> 
> 
>  
> //Axel
>  
>  
>  
> From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net <mailto:openid-specs-mobile-profile-bounces at lists.openid.net>] On Behalf Of Nennker, Axel
> Sent: Mittwoch, 14. Juni 2017 09:52
> To: James.H.Manger at team.telstra.com <mailto:James.H.Manger at team.telstra.com>; ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>
> Cc: openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
> Subject: Re: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text
>  
> inline
>  
>  
> From: Manger, James [mailto:James.H.Manger at team.telstra.com <mailto:James.H.Manger at team.telstra.com>] 
> Sent: Mittwoch, 14. Juni 2017 06:29
> To: Nennker, Axel <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>>; ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>
> Cc: openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
> Subject: RE: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text
>  
> Axel,
>  
> > What are the threats if all client metadata is validated at registration time and all CIBA requests are authenticated?
> -          BadClient is not able to register for the same sector_identifier_uri as GoodPollingClient (regardless of CIBA or OIDC) This is nothing bad introduced by CIBA.
>  
> This is your mistake.
> Multiple clients can register the same sector_identifier_uri — that is the whole point of the sector_id concept (grouping multiple apps). The issue is how does the registration system distinguish BadClient from OtherGoodPollingClient when both register the same sector_id?
> I understand that point. That is the whole purpose of sector_identifier_uri.
> The current Discovery spec does not go into details on validation.
> The OIDC spec, too, does not go into detail how the validation is done.
> There is nothing that is CIBA specific about validation.
>  
> --
> James Manger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170619/558d9983/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4383 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170619/558d9983/attachment-0001.p7s>