<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 25, 2015 at 2:55 AM, Vladimir Dzhuvinov <span dir="ltr"><<a href="mailto:vladimir@connect2id.com" target="_blank">vladimir@connect2id.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Thanks for getting back. My comments are below:<br>
<span class=""><br>
On 23.09.2015 19:21, William Denniss wrote:<br>
> On Wed, Sep 23, 2015 at 4:50 AM, Vladimir Dzhuvinov <<a href="mailto:vladimir@connect2id.com">vladimir@connect2id.com</a><br>
</span><span class="">>> Hi William,<br>
>><br>
>> I really like the improved user experience of FastIDV, bravo!<br>
>><br>
>> Can the OP reliably detect that a given OIDC request is intended for<br>
>> FastIDV, and not just a request that happens to have a login_hint that<br>
>> matches the user's email or phone number? Or is this irrelevant?<br>
>><br>
> I think they can reliably classify it for further processing. This is a<br>
> little complicated, but that's why I tried to split the login into two<br>
> sections:<br>
><br>
> 4.1 – qualification (does the request meet the static requirements of the<br>
> spec for FastIDV processing)<br>
> 4.2.1 – validation (is the request actually valid for the currently<br>
> signed-in user)<br>
><br>
> Keen to here any thoughts on the readability & understandability,<br>
> especially of those sections.<br>
</span>I'll try to implement this independently to get a better feeling of the<br>
internals.<br>
I'll let you know if I have any suggestions about those sections.<br>
<span class=""><br>
> Second, OIDC defines 5 response_type values, is there a reason why only<br>
>> 'code, 'id_token' and 'code id_token' are allowed?<br>
>><br>
> In our implementation we won't issue an access token for FastIDV. Perhaps<br>
> that is overly restrictive?<br>
<br>
</span>With 'code' and 'code id_token' an access token field must be present<br>
for the OIDC token response to also be a valid OAuth2 token response:<br>
<br>
<a href="http://openid.net/specs/openid-connect-core-1_0.html#TokenResponse" rel="noreferrer" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#TokenResponse</a><br>
<a href="http://tools.ietf.org/html/rfc6749#section-4.1.4" rel="noreferrer" target="_blank">http://tools.ietf.org/html/rfc6749#section-4.1.4</a><br>
<br>
You're right that for a FastIDV request the RP has no actual need to<br>
query UserInfo, so the "access_token" could be a dummy string, though<br>
I'm not sure how standard compliant that is (probably not).<br></blockquote><div><br></div><div>True. In our implementation of FastIDV we don't support code currently, so that hasn't been an issue so far.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
BTW, last time I checked Google's OAuth playground, an access token is<br>
issued with scope=openid, and it does give you access to "sub" (and a<br>
few other claims) when submitted to the UserInfo endpoint.<br></blockquote><div><br></div><div>That's correct, our Userinfo endpoint will give back the 'sub', and potentially some public profile data associated with the 'sub' (but not any other data the user has not made public) on scope=openid requests.</div><div><br></div><div>So it's definitely an option to return a valid access token with that access I think.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> There just doesn't seem to be much value in querying userinfo, given the<br>
> premise of this technique is that we are just asserting back information<br>
> that the RP already knows (i.e. 'email' field in the ID Token).<br>
<br>
</span>I understand that the purpose of the 'email' and 'phone' scopes in<br>
FastIDV is to hint about the data type of 'login_hint', and not to<br>
request access to these. </blockquote><div><br></div><div>No, they are real scopes, but happen to also specify the format of the hint (in order to qualify for FastIDV). We won't return 'email', unless we have a grant for the 'email' scope, so it's important for our implementation that the scope is present.</div><div><br></div><div>If you request the email scope, then your hint must be in the format of an email address – otherwise it's not FastIDV as it breaks the "IDP is asserting back what the RP hinted" assumption of FastIDV (e.g. if you request scope=email, but hint=12345).  There is an exception to this, and that is if the RP already has the email grant out of band (covered in Section 4.1 #7) – basically the scope gets treated as an "Additional Scope" ala (Section 4.1 #6) when the format doesn't match the login hint.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">But if FastIDV is to be OIDC compliant and<br>
behave like a subset (as claimed), the OP should not be precluded from<br>
asserting back the information, via the channel specified by the<br>
response_type, i.e. as ID token claim, or at UserInfo endpoint).</blockquote><div><br></div><div>I agree there is nothing to preclude the OP asserting back whatever information they deem fit, and that this is outside the scope of the FastIDV spec. I'm certainly not intending to be restrictive in my language. Do you think any revisions around that is needed?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
When 'email' or 'phone' scope values are passed, should the OP return<br>
the 'email_verified' / 'phone_number_verified' claims? What is your take<br>
on that?<br></blockquote><div><br></div><div>Good question. I'm keen to hear other's opinions, but I would lean towards 'yes'.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> Finally, could we post minor issues to the Bitbucket repo? The issue<br>
>> tracker appears to be hidden or disabled.<br>
>><br>
> +1 :)<br>
><br>
> I've opened up my repo for issue tracking in the interim.<br>
><br>
> Thanks for your comments!<br>
<br>
</span>Thank you too,<br>
<br>
Vladimir<br>
<span class="">><br>
> Best,<br>
> William<br>
><br>
><br>
>> On <a href="tel:21.09.2015%2010" value="+12109201510">21.09.2015 10</a>:30, William Denniss wrote:<br>
>><br>
>> Hi All,<br>
>><br>
>> You may have heard us talking about FastEV and/or FastIDV in the past,<br>
>> perhaps in conversations about AccountChooser.net, as it's a technique we<br>
>> employ there.<br>
>><br>
>> I'm hoping we can standardize this technique into something a little more<br>
>> formal which others may be interested in adopting. To that end, I've<br>
</span>>> published a draft spec <<a href="https://wdenniss.com/fastidv" rel="noreferrer" target="_blank">https://wdenniss.com/fastidv</a>> <<a href="https://wdenniss.com/fastidv" rel="noreferrer" target="_blank">https://wdenniss.com/fastidv</a>> (version control<<a href="https://bitbucket.org/wdenniss/fastidv/" rel="noreferrer" target="_blank">https://bitbucket.org/wdenniss/fastidv/</a>> <<a href="https://bitbucket.org/wdenniss/fastidv/" rel="noreferrer" target="_blank">https://bitbucket.org/wdenniss/fastidv/</a>>).<br>
<span class="">>><br>
>> If you have any comments, I'm keen to hear them. I'll also be joining<br>
>> Monday's AB call.<br>
>><br>
>> Best,<br>
>> William<br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
</span>>> Openid-specs-ab mailing listOpenid-specs-ab@lists.openid.nethttp://<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<div class=""><div class="h5">>><br>
>><br>
>> --<br>
>> Vladimir Dzhuvinov :: <a href="mailto:vladimir@connect2id.com">vladimir@connect2id.com</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>><br>
>><br>
<br>
--<br>
Vladimir Dzhuvinov :: <a href="mailto:vladimir@connect2id.com">vladimir@connect2id.com</a><br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div></div></blockquote><div><br></div><div><br></div><div>Everyone: I'll be attending the OpenID Foundation Workshop today in Mountain View if you want to discuss the spec in person.</div></div></div></div>