[Openid-specs-mobile-profile] html version of the latest discovery draft

John Bradley ve7jtb at ve7jtb.com
Sun Feb 15 16:24:51 UTC 2015


PS I was ordering the sections by the sequence of operations at the RP just for getting it down.  I am not attached to that structure of the sections.

John B.
> On Feb 15, 2015, at 12:59 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> 
> Thanks,
> 
> I will  try to get to this over the next couple of days, and post an update before the next call.
> 
>> On Feb 15, 2015, at 12:33 PM, Torsten Lodderstedt <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>> 
>> Hi John,
>> 
>> thank you for posting this version. Here are my comments:
>> 
>> section 2 - Overview
>> 
>> I think this section should describe the overall idea of the service. As far as I understand there are the following pillars:
>> (1) the interface is designed based on the OAuth flow. After having read this version, I'm not sure which endpoint will actually provide the discovery data to the client. Any new endpoint should be mentioned here as well.
>> - Some rationale why the discovery service's design is based on the OAuth protocol flow is needed as well. As far there are the following aspects:
>> -- RPs shall not get access to the user's MSISDN (or other personal data). This is basically the reason to use a redirect based protocol, which allows the discovery services to ask the user for such data directly.
>> -- Countermeasures are needed in order to prevent open redirection.
>> (2) there is the new concept of a login_hint_token, it should be introduced here.
>> (3) in order to achieve the best possible user experience, the WG recommends to use the discovery service in conjunction with account chooser. This way the user's IDP data can be shared among RPs and there is no need to send her into the discovery process over and over again. 
>> 
>> General questions: 
>> a) What kind of apps do we want to address with the redirect-based protocol? The account chooser might work well for web app but is it the best solution for smartphone apps? I would assume OS-integrated account managers or a NAPPS-based solution would be more appropriate. 
>> b) At least on Android devices, the app can query IMSI/MSISDN from the device (given the user consents). In this case, the app could directly send a POST-request to the discovery service and obtain the IDP metadata (without the need to kick off a browser and send it to the discovery service's HTML endpoint). I think this would result in an even better user experience and simpler integration, so I would suggest we support this flavour as well. 
>> 
>> section 3 and 4
>> 
>> I was a bit suprised to read the AC description (in section 4) before the actual description of the discovery service (and I assume I won't be the only one). I suggest to swap 3 and 4 and describe the discovery protocol first.
>> 
>> I would encourage you to include examples of all protocol messages in this section.
>> 
>> section 4.2.
>> 
>> parameter mcc - why mcc only? Determining the MNO requires the mnc as well.
>> 
>> section 4.5
>> 
>> What is the discovery endpoint? Is it a modified authz/tokens endpoint or is it comparable to the user info endpoint? I'm asking because I don't understand whether the JWT is returned as a certain parameter or whether it is the body content of a response.
>> 
>> I feel text and example do not match in section 4.5. Based on the text I would assume, the result of the discovery endpoint requets is 
>> 
>>   {
>>    "user_iss": "https://discovery-provider.com" <https://discovery-provider.com/>,
>>    "login_hint_token": "i5555551212..."
>>   }
>> 
>> where the login_hint_token contains the following JSON object:
>> 
>> {
>>    "iss": "https://discovery-provider.com" <https://discovery-provider.com/>,
>>    "aud": "https://babytel.com" <https://babytel.com/>,
>>    "exp": 1311281970,
>>    "iat": 1311280970,
>>    "MSISDN": "1234567876543"
>>    "login_hint": "1234567876543"
>>   }
>> 
>> Regarding the login_hint_token itself:
>> 
>> Why does it contain MSISDN and login_hint? I would assume login_hint is the super set of MSISDN.
>> 
>> What is the purpose for including MCC, MNC? They do not identify a certain access line/subscription (potentially user account) with the MNO.  
>> 
>> some nits
>> 
>> section 1.2 
>> 
>> The terms "primary token" and "secondary token" seem to be copied from a NAPPS spec?
>> 
>> section 2
>> 
>> Reated text "Overview." can be removed.
>> 
>> "OpenID Connect Clients using this specification are encouraged to use the OpenID Account chooser service."
>> 
>> I would suggest to a reference to the AC spec here (as this is the first time AC is mentioned). 
>> 
>> best regards,
>> Torsten.
>> 
>> Am 11.02.2015 um 15:55 schrieb John Bradley:
>>> http://openid.bitbucket.org/draft-mobile-discovery-01.html <http://openid.bitbucket.org/draft-mobile-discovery-01.html>
>>> 
>>> The text and XML versions are at https://bitbucket.org/openid/mobile/src <https://bitbucket.org/openid/mobile/src>
>>> 
>>> John B.
>>> 
>>> 
>>> _______________________________________________
>>> 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 <http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150215/aa2c6bb6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150215/aa2c6bb6/attachment.p7s>


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