<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks,<div class=""><br class=""></div><div class="">I will try to get to this over the next couple of days, and post an update before the next call.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 15, 2015, at 12:33 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" class="">torsten@lodderstedt.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
Hi John,<br class="">
<br class="">
thank you for posting this version. Here are my comments:<br class="">
<br class="">
section 2 - Overview<br class="">
<br class="">
I think this section should describe the overall idea of the
service. As far as I understand there are the following pillars:<br class="">
(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.<br class="">
- 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:<br class="">
-- 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.<br class="">
-- Countermeasures are needed in order to prevent open redirection.<br class="">
(2) there is the new concept of a login_hint_token, it should be
introduced here.<br class="">
(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. <br class="">
<br class="">
General questions: <br class="">
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. <br class="">
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. <br class="">
<br class="">
section 3 and 4<br class="">
<br class="">
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.<br class="">
<br class="">
I would encourage you to include examples of all protocol messages
in this section.<br class="">
<br class="">
section 4.2.<br class="">
<br class="">
parameter mcc - why mcc only? Determining the MNO requires the mnc
as well.<br class="">
<br class="">
section 4.5<br class="">
<br class="">
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.<br class="">
<br class="">
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
<br class="">
<br class="">
{<br class="">
"user_iss": <a class="moz-txt-link-rfc2396E" href="https://discovery-provider.com/">"https://discovery-provider.com"</a>,<br class="">
"login_hint_token": "i5555551212..."<br class="">
}<br class="">
<br class="">
where the login_hint_token contains the following JSON object:<br class="">
<br class="">
{<br class="">
"iss": <a class="moz-txt-link-rfc2396E" href="https://discovery-provider.com/">"https://discovery-provider.com"</a>,<br class="">
"aud": <a class="moz-txt-link-rfc2396E" href="https://babytel.com/">"https://babytel.com"</a>,<br class="">
"exp": 1311281970,<br class="">
"iat": 1311280970,<br class="">
"MSISDN": "1234567876543"<br class="">
"login_hint": "1234567876543"<br class="">
}<br class="">
<br class="">
Regarding the login_hint_token itself:<br class="">
<br class="">
Why does it contain MSISDN and login_hint? I would assume login_hint
is the super set of MSISDN.<br class="">
<br class="">
What is the purpose for including MCC, MNC? They do not identify a
certain access line/subscription (potentially user account) with the
MNO.
<br class="">
<br class="">
some nits<br class="">
<br class="">
section 1.2 <br class="">
<br class="">
The terms "primary token" and "secondary token" seem to be copied
from a NAPPS spec?<br class="">
<br class="">
section 2<br class="">
<br class="">
Reated text "Overview." can be removed.<br class="">
<br class="">
"OpenID Connect Clients using this specification are encouraged to
use the OpenID Account chooser service."<br class="">
<br class="">
I would suggest to a reference to the AC spec here (as this is the
first time AC is mentioned). <br class="">
<br class="">
best regards,<br class="">
Torsten.<br class="">
<br class="">
<div class="moz-cite-prefix">Am 11.02.2015 um 15:55 schrieb John
Bradley:<br class="">
</div>
<blockquote cite="mid:8A902ED4-3014-4FC9-83BB-0429B3B1004C@ve7jtb.com" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<a moz-do-not-send="true" href="http://openid.bitbucket.org/draft-mobile-discovery-01.html" class="">http://openid.bitbucket.org/draft-mobile-discovery-01.html</a>
<div class=""><br class="">
</div>
<div class="">The text and XML versions are at <a moz-do-not-send="true" href="https://bitbucket.org/openid/mobile/src" class="">https://bitbucket.org/openid/mobile/src</a></div>
<div class=""><br class="">
</div>
<div class="">John B.</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
Openid-specs-mobile-profile mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a>
</pre>
</blockquote>
<br class="">
</div>
</div></blockquote></div><br class=""></div></body></html>