[Openid-specs-ab] Lite Draft 8

Fri Aug 19 02:23:04 UTC 2011

The user id and other session info is passed to a 3rd party endpoint when it is used as an access token.   Providers want to control what is in there access tokens.

On 2011-08-18, at 10:15 PM, Johnny Bufu wrote:

> 
> On 11-08-18 03:09 PM, Breno de Medeiros wrote:
>> We may want to write a theoretical protocol that requires HTTPs.
>> 
>> It's unlikely people will be able to login to their favorite news site
>> using it. My guess is that this will be extensively used in non-HTTPs
>> contexts, unless it fails altogether as a spec.
>> 
>> Planning for success means that while we strongly encourage HTTPs, we
>> should have mitigation measures for non-HTTPs case.
> 
> What's the leakage scenario when the ID token is used only once with the check session endpoint and not directly as the cookie value?
> 
> Johnny
> 
>> On Thu, Aug 18, 2011 at 15:05, Anthony Nadalin<tonynad at microsoft.com>  wrote:
>>> In the current draft only 3.2.2 mentions HTTPS and does not state that it's mandatory
>>> 
>>> -----Original Message-----
>>> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Johnny Bufu
>>> Sent: Thursday, August 18, 2011 2:56 PM
>>> To: Breno de Medeiros
>>> Cc: openid-specs-ab at lists.openid.net
>>> Subject: Re: [Openid-specs-ab] Lite Draft 8
>>> 
>>> 
>>> On 11-08-18 02:41 PM, Breno de Medeiros wrote:
>>>> There's also a concern with HTTPs support (or lack thereof by some
>>>> clients). An id_token that is used as a session cookie and leaks
>>>> through an unprotected channel can presumably cause less damage than a
>>>> full access_token might.
>>> 
>>> Which parts of the protocol are not required to use HTTPS?
>>> 
>>>> Regardless of HTTPs support, it's usually a good idea to treat cookies
>>>> and API access tokens as different beasts for security reasons, and
>>>> the id_token is functionally a session cookie for the client.
>>> 
>>> The single token would be used one time as an access token for the check session API/endpoint, and the response from there as the actual cookie value/session identifier. Would this now be ok?
>>> 
>>> Johnny
>>> 
>>>> On Thu, Aug 18, 2011 at 13:47, John Bradley<ve7jtb at ve7jtb.com>    wrote:
>>>>> One of the early design decisions was to not mess with the access tokens people are currently using.
>>>>> 
>>>>> I originally wanted to make the access token a JWT so that a single token could be used for both.
>>>>> 
>>>>> The arguments against that were breaking existing API and a desire by people who do want to pass scope inside the token to separate the delegated access scopes from the session management info.
>>>>> They didn't want both in the same token.
>>>>> 
>>>>> Changing to a single token effects session management and the rest of the specs, that is a huge change.
>>>>> 
>>>>> John
>>>>> On 2011-08-18, at 3:46 PM, Johnny Bufu wrote:
>>>>> 
>>>>>> 
>>>>>> On 11-08-16 04:31 PM, John Bradley wrote:
>>>>>>> The two tokens have potentially different scopes and lifetimes.
>>>>>>> 
>>>>>>> There are good reasons for separating resource authorization from session authentication.
>>>>>> 
>>>>>> An OAuth token is, conceptually, an identifier for a grant that the server keeps in its database.
>>>>>> 
>>>>>> Rather than emitting two different tokens, the server could associate the two grants with a single token, and service it differently based on the endpoint the token is presented at:
>>>>>> - the sorter-lived, one-time use grant for the check session
>>>>>> endpoint
>>>>>> - the longer-lived, multiple-use grant for the userinfo endpoint
>>>>>> 
>>>>>> This single token would be a short identifier, not a heavy(er) JWT, suitable for lite clients.
>>>>>> 
>>>>>> On 11-08-17 07:35 PM, John Bradley wrote:
>>>>>>> We did discuss using a JWT for the access token so that it could do
>>>>>>> double duty.
>>>>>>> Some people like Sales Force have existing code for there access
>>>>>>> tokens so they don't want to change that.
>>>>>>> Another issue is token size, making the session token carry all of
>>>>>>> the scope information for the user-info and other endpoints may
>>>>>>> make the token too large to be practical.
>>>>>>> 
>>>>>>> It would also be more complicated for the RP to get right, than
>>>>>>> keeping the session and access grant tokens separate.
>>>>>> 
>>>>>> Full clients wanting a signed JWT for optimization could indicate this in the authorization request. There shouldn't be much of a problem for servers to use the JWT as an identifier / access token for the userinfo grant, but full-clients' life should be made easier by including an equivalent but shorter userinfo access token in the JWT payload.
>>>>>> 
>>>>>> 
>>>>>> Thoughts on this proposal? I'd like to find out if I missed anything that would prevent it from covering the use-cases I've seen brought up on the list recently.
>>>>>> 
>>>>>> 
>>>>>> Johnny
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> _______________________________________________
>>> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110818/58d33349/attachment.p7s>