[OAUTH-WG] What The Fuck Are Yall Trying To Pull

[CenturyLink Customer <[e-mail]>]

[e-mail] E-Mail Belongs To Johnson,Joseph Coley-Wayne...I Go By The Name C.-W. I Don't Now Who Sent This To An E-Mail And Got Redirected To [e-mail] But I'm Appalled, Because Someone Is Who Ever You Sent This E-Mail To The  Person That Had Access To My Account Doesn't Any More. THE Person You Sent This To I Will Figure Out Who It Is With Or Without Your Concern Or Help. Be leave Me John Bradley Got This E-Mail Right After You Sent It To My Account They Sent It To Him. As A Matter Of Fact I Gave Him A Debt Card Last Night And Canceled It Because I Was Under The Impression That He Was A Close Family Friend Because One Of My Twin Sisters Used. To Chill With His Older Sister Fifteen Twenty Years Ago. I'm A Little Up Set So I Haven't Talked To Him About This Cyber Hacking With MyQwest Now Century Link Account. If  Wanted To Talk To Who Ever Sent This E-Mail First Before I Talked To Him. If You Could Please Be So Kind As To Contact Me At 1(612)760-7882 I Go By The Name Of C.-W. Or You Can E-Mail Me At My Other Qwest Account At [e-mail] Your Immediate Assistance Would Be Intriguingly Appreciated Thanks For Your Time And Consideration I Will Be Talking To You Shortly If Not I Will Have No Other Choice Then To Get The Authorities Involved Because My Means Privacy To Comprehending Amongst Other Individuals Has Been Violated Being A Communication Specialist With The US Army National Guard There Is A Strong Bond Using A Communication Service To Identity Cover Up By Using Someone Else Well Beings So The Don't Have To Use There's It Wouldn't Bother Me If Someone Was Using My Account As A Middle Man To Protect The Identity Of The Senders To The Recovers If I Was Profiting From The Communication Information You All Are Discreetly Sharing...    
----- Original Message -----
From: [e-mail]
To: [e-mail]
Sent: Fri, 07 Nov 2014 15:00:20 -0500 (EST)
Subject: OAuth Digest, Vol 73, Issue 11

Send OAuth mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."

--- Begin Message ---

Hi John

Many thanks for the clarifications. FYI, I posted some comments re the 
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution to a 
dedicated thread.

I just wonder is it OK to distinguish between bearer and JWT tokens in 
the spec texts referring to the client processing the access token 
responses. As far as the access tokens are concerned JWT token is just a 
data container which can be useful to AS/RS for the purpose of 
representing the relevant info, I'm curious if the client needs to know 
anything about the access_token format/representations at all.

I'm also curious about the option where the whole token responses are 
JWE encrypted even if TLS is used, with the assymetric key cases; thus 
allowing for the key being always in a plain base64 URL encoded form (in 
the case of the key distributions) but also in other cases I guess...We 
will offer this option for our users as an extension but I wonder if 
someone else here would find it useful

Cheers, Sergey

On 07/11/14 14:15, John Bradley wrote:
> You don't need to use JWT access tokens, you could use a opaque token and introspect it.  However JWT access tokens are likely the simplest answer for getting the clients proof key to the RS.
>
> in http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution you can register a secret for the client and encrypt a symmetric key to it, if you want to use symmetric proofs for the RS.
>
> For performance using symmetric proofs to the RS is not a bad option.
>
> If the client is a server and has appropriate hardware protection for asymmetric keys then using a asymmetric key protected by a HSM is going to be the most secure.
>
> For native public client, they can start the flow with SPOP and when they exchange code and the code verifier get a symmetric proof key for the AT.
>
> SPOP and Proof of possession for AT are complimentary and used to protect different parts of the flow.
>
> The c_hash and at_hash that we added to the id_token in Connect allow a client to determine if a token delivered in the front channel has been tampered with by the user agent.
> (Some AS return at_hash in id_tokens returned from the token endpoint for interoperability, but hat is not required)
>
> John B
>
>
> On Nov 7, 2014, at 8:12 AM, Sergey Beryozkin <[e-mail]> 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
>>> <[e-mail]> 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
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>

--- End Message ---