[Openid-specs-ab] Fast Identity Verification (FastIDV) draft

[Vladimir Dzhuvinov]

Thanks for getting back. My comments are below:

On 23.09.2015 19:21, William Denniss wrote:
> On Wed, Sep 23, 2015 at 4:50 AM, Vladimir Dzhuvinov <vladimir at connect2id.com
>> Hi William,
>>
>> I really like the improved user experience of FastIDV, bravo!
>>
>> Can the OP reliably detect that a given OIDC request is intended for
>> FastIDV, and not just a request that happens to have a login_hint that
>> matches the user's email or phone number? Or is this irrelevant?
>>
> I think they can reliably classify it for further processing. This is a
> little complicated, but that's why I tried to split the login into two
> sections:
>
> 4.1 – qualification (does the request meet the static requirements of the
> spec for FastIDV processing)
> 4.2.1 – validation (is the request actually valid for the currently
> signed-in user)
>
> Keen to here any thoughts on the readability & understandability,
> especially of those sections.
I'll try to implement this independently to get a better feeling of the
internals.
I'll let you know if I have any suggestions about those sections.

> Second, OIDC defines 5 response_type values, is there a reason why only
>> 'code, 'id_token' and 'code id_token' are allowed?
>>
> In our implementation we won't issue an access token for FastIDV. Perhaps
> that is overly restrictive?

With 'code' and 'code id_token' an access token field must be present
for the OIDC token response to also be a valid OAuth2 token response:

http://openid.net/specs/openid-connect-core-1_0.html#TokenResponse
http://tools.ietf.org/html/rfc6749#section-4.1.4

You're right that for a FastIDV request the RP has no actual need to
query UserInfo, so the "access_token" could be a dummy string, though
I'm not sure how standard compliant that is (probably not).

BTW, last time I checked Google's OAuth playground, an access token is
issued with scope=openid, and it does give you access to "sub" (and a
few other claims) when submitted to the UserInfo endpoint.

> There just doesn't seem to be much value in querying userinfo, given the
> premise of this technique is that we are just asserting back information
> that the RP already knows (i.e. 'email' field in the ID Token).

I understand that the purpose of the 'email' and 'phone' scopes in
FastIDV is to hint about the data type of 'login_hint', and not to
request access to these. But if FastIDV is to be OIDC compliant and
behave like a subset (as claimed), the OP should not be precluded from
asserting back the information, via the channel specified by the
response_type, i.e. as ID token claim, or at UserInfo endpoint).

When 'email' or 'phone' scope values are passed, should the OP return
the 'email_verified' / 'phone_number_verified' claims? What is your take
on that?

> Finally, could we post minor issues to the Bitbucket repo? The issue
>> tracker appears to be hidden or disabled.
>>
> +1 :)
>
> I've opened up my repo for issue tracking in the interim.
>
> Thanks for your comments!

Thank you too,

Vladimir
>
> Best,
> William
>
>
>> On 21.09.2015 10:30, William Denniss wrote:
>>
>> Hi All,
>>
>> You may have heard us talking about FastEV and/or FastIDV in the past,
>> perhaps in conversations about AccountChooser.net, as it's a technique we
>> employ there.
>>
>> I'm hoping we can standardize this technique into something a little more
>> formal which others may be interested in adopting. To that end, I've
>> published a draft spec <https://wdenniss.com/fastidv> <https://wdenniss.com/fastidv> (version control<https://bitbucket.org/wdenniss/fastidv/> <https://bitbucket.org/wdenniss/fastidv/>).
>>
>> If you have any comments, I'm keen to hear them. I'll also be joining
>> Monday's AB call.
>>
>> Best,
>> William
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>> --
>> Vladimir Dzhuvinov :: vladimir at connect2id.com
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>

-- 
Vladimir Dzhuvinov :: vladimir at connect2id.com