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

Justin Richer jricher at mitre.org
Mon Nov 14 15:36:45 UTC 2011


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




More information about the Openid-specs-ab mailing list