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

Sorry all for a certain typo in the text below

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
>>
>>