[Openid-specs-ab] Obtaining claims without requiring additional round trips

[Nat Sakimura]

So, one possible "another way" would be to have an option to include more
user info in the id_token.
That way, we can keep the "opaqueness" requirement for the access_token
intact and still accomodate the need for being able to access claims
without a second call.

That actually is how it was done in earlier drafts.

=nat

On Sun, Nov 6, 2011 at 1:39 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  As discussed during the working group call on Thursday, I received
> feedback on the current Connect design from a key Microsoft product
> architect based upon his product’s use cases.  The high-order bit in his
> feedback was that he needs RPs to be able to access claims without making a
> second call to Check ID or UserInfo endpoints.  Per the discussion on the
> call, the requirement to be able to access claims without additional round
> trips seems entirely reasonable and is motivated by real user-interface
> latency concerns.****
>
> ** **
>
> To accomplish this, all claims would be carried in JWT tokens, which would
> then be directly used by the RPs.  This conflicts with the current design
> decision that the access token is opaque and that UserInfo claims can only
> be retrieved by making a second call to the UserInfo endpoint.  I propose
> that we change that decision before declaring implementer’s drafts.****
>
> ** **
>
> Specifically, I would require that, in the normal case, the access token
> is a JWT containing the UserInfo claims (just like the ID Token is a JWT
> containing the logged-in session claims).  If we decide that it’s important
> to allow some implementations to use a different token format, that should
> be the exception, not the default.  In that exceptional case, those IdPs
> must declare in their discovery information that UserInfo claims must be
> retrieved from the UserInfo endpoint, and cannot be directly accessed
> within a JWT access token.****
>
> ** **
>
> I’d promised on the call to write up this proposed change.  This is that
> write-up.  We’ll discuss this on the Monday call.****
>
> ** **
>
>                                                             Best wishes,**
> **
>
>                                                             -- Mike****
>
> ** **
>
> P.S.  Coincidentally, I also independently received essentially the same
> feedback from a different product architect yesterday, based upon his
> review of the specs.****
>
> ** **
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111106/c22ad8e7/attachment.html>