It already does offer a body hash, optional like the rest of the parameters
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00#section-3 (see the “b” parameter) — Justin On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin <[email protected]> wrote: > On 10/11/14 16:56, John Bradley wrote: >> For sending JWE symmetric key to the client the Key Encryption Key is >> client public key provisioned out of band or pushed to the AS in the >> request. (The same applies to key agreement) > Thanks... > > I suggested earlier to consider using 'bearer' token type in the token > response containing a 'key'; probably a bad idea, not sure now (i.e, is it > still a 'bearer', with a client now holding a PoP key :-)), > > may be it should be 'pop' as documents like > http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0 > offer. > > Speaking of "draft-richer-oauth-signed-http-request" - a colleague of mine > raised a related question and I wonder, should this document offer an > *optional* request body hashing as well. > > Thanks, Sergey > >> >> John B. >> On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin <[email protected]> wrote: >> >>> By the way, where is the key encryption key is obtained from in a case >>> where the POP JWK key is encrypted ? Is it a client public key or some key >>> obtained out of band ? >>> >>> Cheers, Sergey >>> On 10/11/14 11:02, Sergey Beryozkin wrote: >>>> Hi John, >>>> Sorry for a delay, >>>> On 07/11/14 21:27, John Bradley wrote: >>>>> Inline. >>>>> On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi >>>>>> On 26/06/14 13:42, Hannes Tschofenig wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I read through three of the OAuth proof-of-possession documents and >>>>>>> made >>>>>>> a few minor changes here and there (mostly editorial & updated >>>>>>> references). >>>>>>> >>>>>>> Here are the three docs: >>>>>>> http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02 >>>>>>> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01 >>>>>>> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01 >>>>>>> >>>>>>> While there are a few open issues I believe that these three documents >>>>>>> are in fairly good shape. >>>>>>> >>>>>>> Is someone willing to do a review? >>>>>>> >>>>>> Few comments to >>>>>> https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01: >>>>>> >>>>>> - it is unclear what the new token_type if any is introduced, for >>>>>> example, the section 6 says no new token type is introduced, while >>>>>> the symmetric example uses a "pop" value and the assymetric key >>>>>> response example says: >>>>>> "The new token type "public_key" is placed into the 'token_type' >>>>>> parameter" >>>>>> >>>>>> Is the new type is actually introduced and it is "pop" and the >>>>>> clients making the requests to RS should use a "POP"/"pop" scheme ? >>>>>> >>>>>> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01 >>>>>> >>>>>> uses "pop" but I'm not 100% sure... >>>>> >>>>> The specs for the client accessing the RS need to define the token type. >>>>> >>>>> There is likely to be more than one of those, signed message and TLS >>>>> channel binding. >>>>> >>>> I wonder, should it only be this PoP key distribution spec that would >>>> use "pop", which is really about getting a regular token 'enhanced' with >>>> a key. If I have AS returning a bearer token with a response containing >>>> "token_type":"bearer", then when this AS receives a client token request >>>> with a "token_type":"pop" it just means the bearer token to be returned >>>> would have a key parameter bound to it. >>>> >>>> Note IMHO it does not matter for the client whether the actual token >>>> representation is JWT or an index, it is still a "token_type":"bearer" >>>> as far as the client getting a token response is concerned. >>>> So it won't lead to the proliferation of the new token types. >>>> >>>> Something else that I wanted to suggest - can make no much sense but >>>> here it goes: >>>> >>>> Refresh tokens and indeed id_token OIDC tokens are just access token >>>> response parameters but for them to be included in the response all what >>>> is needed is for the client to include an extra scope in the redirection >>>> request... Just a thought... >>>> >>>> >>>>> I am guessing that the channel binding one wouldn't support symmetric >>>>> proof keys. >>>>> >>>>> Those specs may wind up profiling this spec to limit particular key >>>>> types etc. >>>>> >>>>> The token_type in the request is saying give me a token to use over >>>>> this request method to the RS. >>>>> >>>>> The AS might use the same logic to produce a AT for signed request and >>>>> TLS. >>>>> >>>>> The other parameters are: >>>>> "aud" so that the AS can deal with multiple RS perhaps all with >>>>> different encryption keys and some using introspection. >>>>> "alg" indicating the alg of the proof key "HS256", "RS256", and >>>>> "ECDSA" being the current likely options. >>>>> (looking at that now I wonder if we also need to say anything about >>>>> key length/curve, I hope all of that can be sorted out in >>>>> registration so some sensible defaults would work for length/curve) >>>>> >>>>> Those being important to any client RS protocol. >>>>> >>>> thanks for this extra info, >>>>> >>>>>> >>>>>> - The assymetric key example suggests that just a JWS-signed access >>>>>> token is returned. This implies a client can easily introspect it - >>>>>> which is not a big problem in this case - but it leads the client >>>>>> toward writing a code that is bound to an access token structure - >>>>>> therefore such a client code won't inter-operate with the AS sending >>>>>> a bearer token; IMHO the access token structure should absolutely be >>>>>> opaque to the clients, i.e, if it is JWT then it must be JWE protected >>>>> >>>>> The intention is not to limit it to just JWS signed JWT, that should >>>>> be expanded if not clear. >>>>> >>>>> SAML has the same problem with people sniffing tokens, so I agree that >>>>> the client should be precluded in the spec from doing that. >>>>> Forcing encryption of all the AT may be overkill and have negative >>>>> performance implications if not required for other reasons. >>>>> Nothing stops the AS and RS from using JWE encrypted JWT. Given that >>>>> in the symmetric key case between the AS and RS case a A128CBC-HS256 >>>>> has AEAD Authenticated encryption so you don't need to sign the JWT >>>>> separately as an optimization. (I personally prefer A128CBC-HS256 >>>>> over HS256 given that the performance hit is small, but that is just me.) >>>> I'm afraid I'm not following that :-), but given that we do implement >>>> "A128CBC-HS256 over HS256" now, I will afford asking, are you referring >>>> here to the case of the PoP key being distributed in a plain form over >>>> TLS vs being JWE-encrypted with "A128CBC-HS256 over HS256" ? >>>>> >>>>> Requiring encryption is probably overkill. >>>> I understand, as long as the client treats a JWS sequence as an opaque >>>> blob, it is fine... >>>> >>>> Thanks >>>> Sergey >>>>> >>>>> John B. >>>>> >>>>> >>>>>> >>>>>> Thanks, Sergey >>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>> >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
