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

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Mon May 29 12:40:27 UTC 2017


That pseudo code was an intermediate step and only applicaple to RPs who did not register a sector_identifier_uri and NEVER intend to do so.
Registering one later would break the sub of all customers which is certainly bad :)
That thought led to demanding a sector_identifier_uri to be mandatory for all CIBA SPs.

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."

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/

and

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?

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?

Cheers
Axel


From: Manger, James [mailto:James.H.Manger at team.telstra.com]
Sent: Donnerstag, 25. Mai 2017 05:23
To: openid-specs-mobile-profile at lists.openid.net; nicolas.aillery at orange.com; Nennker, Axel <Axel.Nennker at telekom.de>
Subject: RE: [Openid-specs-mobile-profile] Issue #52: CIBA Pairwise Identifiers Structuring Text (openid/mobile)

That pseudo-code is dangerous. We definitely do NOT want to hash the raw client.jwks_uri or client.notification_uri. We need to hash the domain name from these URIs. That allows the app owner to later specify a sector_identifier_uri (in the same domain) if they are deploying a related app (on a different domain) that needs to recognize the same users.

CIBA cannot say "Sector Identifier Validation at registration time is out-of-scope", as in section 4 "Pairwise identifiers" of the "24 Mai" version. 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.

Mandating that CIBA clients have registered a sector_identifier_uri is reasonable.
We should also mandate (or at least very strongly recommend) that sector_identifier_uri has a specific path, such as https://<sector_id>/.well-known/openid/apps.json<https://%3csector_id%3e/.well-known/openid/apps.json>. Otherwise an attacker can pretend to have a given sector_id by finding/creating a resource (or redirect) anywhere on https://<sector_id>/<https://%3csector_id%3e/> that returns a JSON array with the attacker's URI.

--
James Manger


From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com>
Sent: Wednesday, 24 May 2017 7:41 PM
To: Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>
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 (openid/mobile)

Hello Axel,

   I agree with mandatory sector_identifier_uri when using CIBA.
   There is also a need to add security in the section "5.  "sector_identifier_uri" Validation" of OpenID.Registration, if we want to prevent the spoofing of sector_identifier_uri by a malicious Client,

Regards,

Nicolas

De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>
Envoyé : mercredi 24 mai 2017 11:31
À : openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Objet : Re: [Openid-specs-mobile-profile] Issue #52: CIBA Pairwise Identifiers Structuring Text (openid/mobile)

A CIBA spec mandating sector_identifier_uri if the OP uses Pairwise Identifiers is here:
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.5.1.1

WDYT?

//Axel

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Nennker, Axel
Sent: Mittwoch, 24. Mai 2017 10:06
To: 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 (openid/mobile)


Hi all,



I created https://bitbucket.org/openid/mobile/issues/52/ciba-pairwise-identifiers-structuring-text to keep track of this.



In pseudo code the calculation of sub could look like this:

// Client is authenticated at this point

If (client.sector_identifier) then

  // if we have a registered client identifier then use it

  sub = SHA-256 ( client.sector_identifier || local_account_id || salt );

else

  //need to determine sector_identifier to use as non is registered for this Client

  If (request_object && client.jwks_uri) then

    // request object signature is valid and key from client.jwks_uri was used to sign it

    sub = SHA-256 ( client.jwks_uri || local_account_id || salt );

  else

    // no registered sector_identifier, no request_object

    if (client.notification_uri) then

      // not polling but notification mode

      sub = SHA-256 ( client.notification_uri || local_account_id || salt );

    else

      // polling mode but not sector_identifier registered

      response.setError("invalid_request");

      logError("invalid_request", "no sector identifier for %s", client.id);

      return;

    endif

  endif

endif

// have sub that is a pairwise identifier here



Having said all that I currently tend to change the spec to say:

"In CIBA the Client MUST specify the sector_identifier_uri at registration time if the OP uses Pairwise Identifiers which is strongly recommended".



Should we make sector_identifier_uri mandatory for CIBA and cull all other Pairwise Identifier text?



Cheers

Axel


Pairwise Identifier Algorithm

https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg



"sector_identifier_uri" Validation

https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation



-----Original Message-----
From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Axel Nennker
Sent: Dienstag, 23. Mai 2017 15:33
To: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Subject: [Openid-specs-mobile-profile] Issue #52: CIBA Pairwise Identifiers Structuring Text (openid/mobile)



New issue 52: CIBA Pairwise Identifiers Structuring Text https://bitbucket.org/openid/mobile/issues/52/ciba-pairwise-identifiers-structuring-text



Axel Nennker:



Should the text regarding Pairwise Identifiers be in its own section or should it stay in the sections on polling and notification?



Polling: https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.5.1.1

Notification: https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.5.3.3



References to other specs:

Core: https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg

Validation of sector_identifier: https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation





Axel



Responsible: ignisvulpis

_______________________________________________

Openid-specs-mobile-profile mailing list Openid-specs-mobile-profile at lists.openid.net<mailto:Openid-specs-mobile-profile at lists.openid.net>

http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170529/0589767b/attachment-0001.html>


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