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

Torsten Lodderstedt torsten at lodderstedt.net
Sun Feb 15 15:33:15 UTC 2015


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",
    "login_hint_token": "i5555551212..."
   }

where the login_hint_token contains the following JSON object:

{
    "iss": "https://discovery-provider.com",
    "aud": "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
>
> The text and XML versions are at https://bitbucket.org/openid/mobile/src
>
> John B.
>
>
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> 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/c2b31771/attachment.html>


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