[Openid-specs-mobile-profile] Issue #52: CIBA Pairwise Identifiers Structuring Text (openid/mobile)

Manger, James James.H.Manger at team.telstra.com
Tue May 30 08:09:18 UTC 2017

> only applicaple to RPs who did not register a sector_identifier_uri and NEVER intend to do so.

We should assume that an RP that hasn't registered a sector_id just hasn't had enough experience yet (with app versions, company reorgs, re-branding, i18n etc) to know that they will need it eventually. We should expect the RP to need a sector_id at some point in the future.

> Registering one later would break the sub of all customers which is certainly bad :)

But it doesn't have to break all subs if only the host part of the jwks_uri or notification_uri is used. That host can subsequently server a sector_identifier_uri.

> That thought led to demanding a sector_identifier_uri to be mandatory for all CIBA SPs.

Still worthwhile to make RPs consider the importance of a stable long-term domain for their sector_id.

> What the contents of the document at the siu is is still unclear to me.
> Registration describes siu in https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation as
"The value of the sector_identifier_uri MUST be a URL using the https scheme that references a JSON file containing an array of redirect_uri values. The values registered in redirect_uris MUST be included in the elements of the array, or registration MUST fail. This MUST be validated at registration time; there is no requirement for the OP to retain the contents of this JSON file or to retrieve or revalidate its contents in the future."

So we extend that from "an array of redirect_uri values" to "an array of redirect_uri, jwks_uri, and notification_uri values".
It is backwards compatible (an old systems just ignores jwks_uri and notification_uri values as if they were redirect_uri values for some other related apps).

> Where do you see new rules regarding siu in CIBA?
"It must be in-scope because CIBA is adding new rules that jwks_uri and/or notification_uri needs to be listed in the content at sector_identifier_uri."
CIBA currently does not say anything about the file which means that an RP using both CIBA and front-channel would have redirect_uri values in it.
I read CIBA in such a way that an RP who does not use front-channel would have an empty array as the contents of the siu document.
There are currently no rules about notification_uri which needs to be registered for the Client separately.

> I am not sure whether CIBA needs the siu document contents to be changed.

> Let's say we have two RPs: With

iss "https://client.example.org/" and iss https://client.other_company.example.net/


the siu is https://other.example.net/file_of_redirect_uris.json"

and there is a new back-channel-only RP with the same siu with iss and notification_uri

iss "https://petrol-pumps.exmaple.net/" and notification_uri "https://petrol-pumps.exmaple.net/cb"

> Would you change the siu json to include the notification_uri


> or is it enough to register the notification_uri for the client separately?


> How would the validation of the to-be registered notification_uri look like?

Just like redirect_uri validation.
"The value registered in notification_uri MUST be included in the items of the array at the sector_identifier_uri, or registration MUST fail."

> Registration does not put much constraint on validation https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation
> Should CIBA be more strict and why?

CIBA (and Registration) should be stricter.
Having an app's URI in the array at the sector_identifier_uri gives the app the authority to receive the 'sub's of the sector_id (domain). Instead of allowing every URI in a domain to convey that authority, it is much safer if only 1 specific address in that domain (eg https://<sector_id>/.well-known/openid/apps.json<https://%3csector_id%3e/.well-known/openid/apps.json>) can convey that authority.

> Axel

James Manger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170530/705bf537/attachment.html>

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