[Openid-specs-ab] Fast Identity Verification (FastIDV) draft
wdenniss at google.com
Mon Oct 26 17:08:01 UTC 2015
On Fri, Sep 25, 2015 at 2:55 AM, Vladimir Dzhuvinov <vladimir at connect2id.com
> 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
> 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:
> 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).
True. In our implementation of FastIDV we don't support code currently, so
that hasn't been an issue so far.
> 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.
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.
So it's definitely an option to return a valid access token with that
access I think.
> > 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.
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.
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.
> 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).
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?
> 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?
Good question. I'm keen to hear other's opinions, but I would lean towards
> > 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,
> > 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
> >> employ there.
> >> I'm hoping we can standardize this technique into something a little
> >> 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/> <
> >> 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://
> >> --
> >> 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
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
Everyone: I'll be attending the OpenID Foundation Workshop today in
Mountain View if you want to discuss the spec in person.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab