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

Anthony Nadalin tonynad at microsoft.com
Tue Nov 15 01:28:12 UTC 2011

Issue that we have not specifying a token type is that there will be no way to know what folks are using, the purpose of basic profiles is specify usage not extensibility

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Justin Richer
Sent: Monday, November 14, 2011 7:37 AM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Obtaining claims without requiring additional round trips

I really don't like specifying the format of the access token, particularly since we are looking to use a layered setup here with a single AS handling both identity and service authorization. To do this, we need the flexibility to make the token take different forms, and I know of others who will have the same issue. I believe that once we start cramming things into the token like that, other protocols will want to do the same, and we'll be looking at a mega-JWT that doesn't fit anywhere. Let the token stay a token -- an abstract reference used to access other stuff.

Plus, doesn't this resort to putting user info claims back onto the front channel? That's one of the major leakage points that plagues OpenID 2.0 and keeps it from being higher LOA. Plus, it forces the IdP to always send the claims, whether the client actually wants or needs them or not.

I'd be fine with this being an alternative mode or extension or something, since the User Info Endpoint could still accept this token with all of its encoded bits and return the JSON document. But I am really against this being the default mode of Connect.

 -- Justin

On Sat, 2011-11-05 at 16:39 +0000, Mike Jones 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

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net

More information about the Openid-specs-ab mailing list