[Openid-specs-mobile-profile] Issue #52: CIBA Pairwise Identifiers Structuring Text (openid/mobile)
nicolas.aillery at orange.com
nicolas.aillery at orange.com
Wed May 24 09:40:52 UTC 2017
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
Envoyé : mercredi 24 mai 2017 11:31
À : 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/20170524/7c15a399/attachment-0001.html>
More information about the Openid-specs-mobile-profile
mailing list