[Openid-specs-mobile-profile] html version of the latest discovery draft
torsten at lodderstedt.net
Sun Feb 15 15:33:15 UTC 2015
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
- 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
-- 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
(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.
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
I would encourage you to include examples of all protocol messages in
parameter mcc - why mcc only? Determining the MNO requires the mnc as well.
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
where the login_hint_token contains the following JSON object:
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.
The terms "primary token" and "secondary token" seem to be copied from a
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).
Am 11.02.2015 um 15:55 schrieb John Bradley:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-mobile-profile