[Openid-specs-mobile-profile] Mobile Profile WG Call

nicolas.aillery at orange.com nicolas.aillery at orange.com
Thu Jun 1 10:03:29 UTC 2017


Hello,



   Following yesterday call, here are some ideas about challenging the sector_identifier_uri at registration.



   As soon as we plan to generate sub in a backchannel mode, we may encounter Clients that only use this backchannel mode.

   In order to generate the sub, we shall use the sector_identifier_uri (as redirect_uri makes no sense, and notification_uri seems to specific).



   In frontchannel mode, a Client using a fake sector_identifier_uri or redirect_uri would not be able to retrieve the Access Tokens or ID Tokens. The authenticity of the Client is validated at usage, not at registration.

   As soon as we introduce backchannel mode, I think we should introduce the validation of the Client's sector_identifier_uri at registration.



   I think that the registration spec should evolve in order to handle the security requirements of backchannel mode.





   One proposal would be to use the sector_identfier_uri to retrieve something richer than a simple array and to use challenges (validated at registration).

   These challenges can use symmetric crypto, asymmetric crypto or hashes.



   - Here is an example with SYM crypto:

            A call to the sector_identifier_uri returns:

                        {

                                    Redirect_uri: [],

                                    Notification_endpoints : [],

                                    Challenges: [ { value_to_be_signed: <value_to_be_signed> , signature: <signature>} ]

                        }

            At registration, the client supplies the OP with the value_to_be_signed, the associated signature (HMAC) and the secret key used to sign. The OP can easily verify that the registering Client own the secret key.

            Using an array of challenges, the Client can easily manage the lifecycle of the value_to_be_signed and/or certificates.





   - Here is an example with ASYM crypto:

            A call to the sector_identifier_uri returns:

                        {

                                    Redirect_uri: [],

                                    Notification_endpoints : [],

                                    Challenges: [ { value_to_be_signed: <value_to_be_signed> , certificate : <certificate>} ]

                        }

            At registration, the client supplies the OP with the value_to_be_signed and the associated signature. The OP can easily verify that the registering Client own the private key.

            Using an array of challenges, the Client can easily manage the lifecycle of the value_to_be_signed and/or certificates.





   - Here is an example with HASH crypto (using PKCE concepts):

            A call to the sector_identifier_uri returns:

                        {

                                    Redirect_uri: []

                                   Notification_endpoints : []

                                    Challenges: [ { code_challenge: <code_challenge> } ]

                        }

            At registration, the client supplies the OP with the code_challenge  and the code_verifier. The OP can easily verify that the Client own code_verifier related to the code_challenge.

            Using an array of challenges, the Client can easily change the challenges so that they cannot stay to long (the longer they stay, the more risk there is that a malicious Client find the code_verifier).





    In order to have a generic proposal, we could use the following object:

                        {

                                    Redirect_uri: []

                                    Notification_endpoints : []

                                    Challenges: [

                                                {

                                                challenge_id : <challenge_id>,      //must be unique within the array

                                                challenge_type: <challenge_type>, // e.g. SYM, ASYM, HASH

                                                code_challenge: <code_challenge>, //only when type==HASH

                                                signature: <signature>, //only when type==SYM

                                                certificate : <certificate>, //only when type==ASYM

                                                value_to_be_signed: <value_to_be_signed>  // only when type==SYM or type==ASYM

                                                }

                                   ]

                        }

     At registration, the client supplies the OP with the challenge_id and the relevant verifier depending of the challenge_type (e.g. code_verifier for HASH, the secret key in SYM and the associated signature in ASYM)



Regards,



Nicolas




De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de Hjelm, Bjorn via Openid-specs-mobile-profile
Envoyé : mercredi 31 mai 2017 12:51
À : openid-specs-mobile-profile at lists.openid.net
Objet : Re: [Openid-specs-mobile-profile] Mobile Profile WG Call

Agenda
·         Feedback on Workshop meeting minutes [all]
·         Polling vs Notification [Axel]
·         FAPI WG feedback on MODRNA Specifications [Bjorn/John]
·         Issue Tracker [All]
·         #52<https://bitbucket.org/openid/mobile/issues/52/ciba-pairwise-identifiers-structuring-text>
·         #53<https://bitbucket.org/openid/mobile/issues/53/ciba-terminology-consumption-device>
·         #54<https://bitbucket.org/openid/mobile/issues/54/ciba-client-notification-endpoint>
·         #55<https://bitbucket.org/openid/mobile/issues/55/ciba-signed-result-objects>


-----Original Appointment-----
From: Hjelm, Bjorn [mailto:Bjorn.Hjelm at VerizonWireless.com]
Sent: Tuesday, May 23, 2017 5:12 AM
To: Hjelm, Bjorn; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Subject: [E] [Openid-specs-mobile-profile] Mobile Profile WG Call
When: Wednesday, May 31, 2017 4:00 PM-5:00 PM Europe/Berlin.
Where: https://global.gotomeeting.com/join/927253461



_________________________________________________________________________________________________________________________

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/20170601/0ee516ea/attachment-0001.html>


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