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

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Mon Jun 19 10:25:40 UTC 2017

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?



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


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.


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.


From: Openid-specs-mobile-profile [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


From: Manger, James [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


> 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/1d559f61/attachment-0001.html>

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