Re: [OAUTH-WG] Wrapping access token and codes

Or if the confidential client does
HTTP Accept: application/jose, why don't

reply with the whole OAuth2 token response JWE or JWS encoded as opposed 
to tweaking individual token response parameters...

may be I'm getting carried away here but I'm getting quite positive and 
even excited about the options JWE/JWS can offer :-).

Sergey
On 07/11/14 11:12, Sergey Beryozkin wrote:
> Hi
> On 06/11/14 18:51, Bill Mills wrote:
>> So you're wanting end to end security not relying on TLS?
>>
> I was not really thinking about HTTPS vs HTTP in this case. I'm kind of
> in the process of appreciating what JWE/JWS can do and I can't help
> trying to consider it applying at the every possible opportunity :-)
>>
>> Have you seen the new draft on protecting codes from interception?
>>   Currently called SPOP but needs a different name.
>>
> Do you mean this one:
> http://tools.ietf.org/html/draft-ietf-oauth-spop-02
> ?
>
> Yes I did - it's a different mechanism though, I guess it is of most
> help to the pubic clients, though we do not distinguish in our code, a
> confidential client can use the SPOP mechanism too.
>
> I think the wrapping idea is probably what
> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01#ref-10
>
>
> talks about with respect to distributing a key using a JWE option.
> That actually looks interesting; I haven't analyzed it much yet but
> apparently it is tied to the access token being necessarily in a JWT
> format, may be I did not get it right yet.
>
> I guess it just can be interesting even in the TLS case. I believe
> people do not mind doing the extra protection even in the TLS cases.
>
> Or take the implicit grant; if the wrapped access token reaches a client
> which is aware of WebCrypto API then it is probably making this grant
> much more secure...
>
> Sergey
>
>> On Thursday, November 6, 2014 4:12 AM, Sergey Beryozkin
>> <sberyozkin@gmail.com> wrote:
>>
>>
>> Hi
>>
>> Does it make sense to consider supporting an access token or code
>> wrapping as part of the standard OAuth2 responses ?
>>
>> For example, if a client has registered its public key with AS then say
>> the access token response would contain the regular
>>
>> {"access_token":"1234345"}
>>
>> except that "1234345" would actually be a JWE RSA-OAEP wrapped opaque
>> token with a client's public key being used. Or a direct key encrypted
>> token if the client and the server only share the client secret
>> allocated to the client during the registration.
>>
>> The net result is that only the registered confidential client would be
>> able to extract the actual opaque access token. The response would
>> actually be
>>
>> {"access_token":"1234345", wrapped:true}.
>>
>> I definitely plan to use this approach as a simple mechanism for making
>> a safer distribution of mac keys as part of access token responses; but
>> IMHO it can be handy for minimizing the possibility of the
>> access/refresh tokens or codes being intercepted...
>>
>> Sergey
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com