[Openid-specs-ab] Validation Characteristics of UserInfo Endpoint
sakimura at gmail.com
Sat Jan 15 01:14:33 UTC 2011
I agree in sending the entire JWT to the Signature Validation Endpoint.
UserInfo Endpoint looks like a kind of such.
On Sat, Jan 15, 2011 at 9:55 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> I was thinking that the access tokens for the various endpoints would be in
> the JWT. The JWT would only be the access token for the user info endpoint.
> John B.
> On 2011-01-14, at 9:51 PM, Nat Sakimura wrote:
> On Sat, Jan 15, 2011 at 9:03 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> I think exchanging code for the access token in the web server flow is
>> equivalent proof for any assertion returned along with the access token in
>> the web server flow.
>> On your second question, that's why I was asking if the JWT returned in
>> the web server flow could also be the access token. Given that it is a new
>> endpoint there are no backwards compatibility issues.
>> It works for the user agent flow as well, as far as I can tell. I was
>> discussing a similar idea with the UMA people for there dumb mode flow.
> Unless, of course, we return the access tokens for multiple endpoints. We
> may not want to reveal more information than necessary.
>> John B.
>> On 2011-01-14, at 8:52 PM, Nat Sakimura wrote:
>> I have a question about the validation characteristics of the UserInfo
>> According to the openidconnect.com proposal, the Client is supposed to
>> make a query to the UserInfo Endpoint if it does not wish to validate the
>> signature on the positive assertion that includes the access_token. It sends
>> the user_id and access_token to the UserInfo Endpoint and it gets back
>> asserted_user among other things. If asserted_user is true, then the
>> validation was successful.
>> It makes some sense in the User-Agent Flow. In case of the User-Agent
>> Flow, the assertion is returned through the browser/user-agent so it cannot
>> be trusted. It may have been tampered etc. Thus, assuming it is operated by
>> the Authorization Server, sending the query to the UserInfo Endpoint has
>> value. Also, there is an additional value in doing so because the UserInfo
>> Endpoint can validate that it is the same User-Agent that was found at the
>> End User Authorization Endpoint, that the User-Agent has not been swapped.
>> However, it does not make much sense in case of the Web Server like flows
>> where 'code' is exchanged to 'access_token' over the direct https
>> Client-Server channel. All the validation characteristics for the UserInfo
>> Endpoint already exists in the Access Token Endpoint. Thus, UserInfo query
>> is redundant as a validation process and becomes an OPTIONAL user attribute
>> Am I missing something? If I am right, then the 'MUST check' language
>> comes in for the validation through the UserInfo Endpoint only in the
>> User-Agent Flow. In fact, the assertion does not even have to be signed by
>> the Server in case of Web Server/Artifact Flow.
>> Also, in the current openidconnect.com proposal, only the access_token
>> and user_id but not the entire token is sent to the UserInfo Endpoint. It
>> was argued earlier that this was done because UserInfo Endpoint ought to be
>> a regular protected resource. I thought that was a good reason. However, now
>> I consider it as a validation endpoint, I find some value in sending the
>> entire JWT as well. If the JWT was using RSA or EC-DSA as a signature
>> algorithm, then the validation endpoint can be operated by a separate entity
>> than the Server, without assuming any additional characteristics on the
>> access_token. It probably is worth considering.
>> Nat Sakimura (=nat)
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> Nat Sakimura (=nat)
Nat Sakimura (=nat)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab