[Openid-specs-ab] Validation Characteristics of UserInfo Endpoint

Nat Sakimura sakimura at gmail.com
Tue Jan 18 16:11:55 UTC 2011


Right. If you can sign and encrypt for the User-Agent, yes.
The assumption was that since the "user-agent" is dumb enough that it cannot
even validate HMAC, it would not be able to do the encryption either.

For a rich client apps, sign+encrypt is the way to go, I think.

=nat

On Tue, Jan 18, 2011 at 9:09 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> If you encrypt and sign to the RP the User agent flow would have the same
> security characteristics as the Web Server flow.  This is arguably the most
> efficient flow as the RP doesn't need to make any direct call to the IdP.
>
> Both flows allow the RP to rely on SSL rather than the signature to
> validate the sender.
>
> I think the RP should select one over the other based on the user agent to
> avoid sending large assertions through mobile devices, or always use the web
> server flow if they want LoA 2 but don't want to support encryption.
>
> I think mobile support argues for making the web server flow the default or
> MTI flow for RP.
>
> That way LoA 2 would be the default, from a spec point of view.   Nothing
> stops a RP from just doing a LoA1 User Agent flow, however that may not work
> well for all user devices.
>
> John B.
>
>
> On 2011-01-17, at 10:52 PM, Nat Sakimura wrote:
>
> Thanks Breno for your comment.
>
> On Tue, Jan 18, 2011 at 4:09 AM, Breno de Medeiros <breno at google.com>wrote:
>
>> My preference is that the User-Agent and WebServer flows be as similar as
>> possible. It will make easier to change between implementations, and
>> facilitate developer's understanding of the OpenIDConnect flows.
>
>
> As it is written now, the UAB and AB shares exactly the same Core model and
> abstract protocol.
>
>
>>
>> Since User-Agent has a more limited operational context in terms of
>> security, I suggest we design an end-to-end solution for it, and then make
>> minimal changes to add support for WebServer flow.
>>
>
> Actually, WebServer flow requires much less security measures than
> User-Agent flow. If we start from User-Agent flow, it amounts to removing
> various requirements. For example, in Web Server/Artifact Flow, you do not
> need to sign the access_token etc. if you just want LoA1 (which is the
> highest User-Agent flow can go.)
>
> =nat
>
>
>>
>>
>> On Fri, Jan 14, 2011 at 19:06, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>
>>> An existing graph API Endpoint would need to be modified to return a JWT
>>> anyway.
>>>
>>> I think it is cleaner to keep them as separate protected resources.
>>>
>>> We are adding complexity for backwards compatibility with legacy oAuth.
>>>  Seems ironic.
>>>
>>> John
>>>
>>> Sent from my iPad
>>>
>>> On 2011-01-14, at 11:51 PM, Nat <sakimura at gmail.com> wrote:
>>>
>>> The complication seem to be the fact that some use vases are overloading
>>> the UserInfo endpoint. If we want to use an existing graph API for this
>>> purpose, it obviously does not work.
>>>
>>> =nat
>>>
>>> On 2011/01/15, at 10:18, John Bradley < <ve7jtb at ve7jtb.com>
>>> ve7jtb at ve7jtb.com> wrote:
>>>
>>> Assuming the JWT is signed then a smart client validates the sig and a
>>> dumb one sends it to the Sig validation endpoint otherwise known as the user
>>> info endpont.
>>>
>>> The endpoint then only needs to validate the sig on the JWT and hand it
>>> back in the simple case.
>>>
>>> John B.
>>> On 2011-01-14, at 10:14 PM, Nat Sakimura wrote:
>>>
>>> I agree in sending the entire JWT to the Signature Validation Endpoint.
>>> UserInfo Endpoint looks like a kind of such.
>>>
>>> =nat
>>>
>>> On Sat, Jan 15, 2011 at 9:55 AM, John Bradley < <ve7jtb at ve7jtb.com><ve7jtb at ve7jtb.com>
>>> 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><ve7jtb at ve7jtb.com>
>>>> 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.
>>>>>
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>>
>>>>> 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:
>>>>>
>>>>> Hi.
>>>>>
>>>>> I have a question about the validation characteristics of the UserInfo
>>>>> Endpoint.
>>>>>
>>>>> According to the <http://openidconnect.com/><http://openidconnect.com/>
>>>>> 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
>>>>> query.
>>>>>
>>>>> 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 <http://openidconnect.com/><http://openidconnect.com/>
>>>>> 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)
>>>>> <http://www.sakimura.org/en/> <http://www.sakimura.org/en/>
>>>>> http://www.sakimura.org/en/
>>>>>  <http://twitter.com/_nat_en> <http://twitter.com/_nat_en>
>>>>> http://twitter.com/_nat_en
>>>>>  _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> <Openid-specs-ab at lists.openid.net> <Openid-specs-ab at lists.openid.net>
>>>>> Openid-specs-ab at lists.openid.net
>>>>>  <http://lists.openid.net/mailman/listinfo/openid-specs-ab><http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> <http://www.sakimura.org/en/> <http://www.sakimura.org/en/>
>>>> http://www.sakimura.org/en/
>>>>  <http://twitter.com/_nat_en> <http://twitter.com/_nat_en>
>>>> http://twitter.com/_nat_en
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> <http://www.sakimura.org/en/> <http://www.sakimura.org/en/>
>>> http://www.sakimura.org/en/
>>>  <http://twitter.com/_nat_en> <http://twitter.com/_nat_en>
>>> http://twitter.com/_nat_en
>>>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>
>>
>> --
>> --Breno
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110119/bd9e44eb/attachment.html>


More information about the Openid-specs-ab mailing list