Re: [OAUTH-WG] Updated OAuth PoP documents

John Bradley <> Tue, 11 November 2014 17:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 17A7F1A00F7 for <>; Tue, 11 Nov 2014 09:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0GrX-mn10FRF for <>; Tue, 11 Nov 2014 09:18:04 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 342CC1A0055 for <>; Tue, 11 Nov 2014 09:16:54 -0800 (PST)
Received: by with SMTP id bs8so2287586wib.17 for <>; Tue, 11 Nov 2014 09:16:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=H81lUJ/f0G/hmRmSLolW9H59UMU822Qm+/lw1Gg46cU=; b=WZt4RunyR29cOE++l0pPsKsvyVwOfzmSNcOv3CqXmsN27nHrWACyPM5QxjPDPKxUkY Tih/sBs/gFnxMtlr4xRWTtm8k5eKF5z5vIAyZB2UR3SyBifrYzRSdFEtGnR4pzm+7EWW lQw9ho7gP4xXiFyJyDW7R/zN2I3nHH4YWFk6It20QaJImUyY1SyRxLDGo/GF4HjFnqYE WhmmIcKKbnw6EKPDfIm0BIIbDeQoaH8qvNSnQUouJxE3gvaDr89zmgJ4u3IkpyT1/cPR Pm3wmCFN3MgJAbhqQmL4xf7WhvZuekq6D3cLzleIlgjBCLGlhbcvFhYkwktkmZtnHeuv doYg==
X-Gm-Message-State: ALoCoQk9D+m3LfMlL6GmtA5FPhJnp9hNjGmU67CpfEvKzyOtod3volzk5jzQUiX9IRKZsEm0QTyQ
X-Received: by with SMTP id fo7mr43330166wib.79.1415726212835; Tue, 11 Nov 2014 09:16:52 -0800 (PST)
Received: from ( []) by with ESMTPSA id fa16sm18275420wid.5.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 09:16:51 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <>
In-Reply-To: <>
Date: Tue, 11 Nov 2014 07:16:51 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Sergey Beryozkin <>
X-Mailer: Apple Mail (2.1878.6)
Subject: Re: [OAUTH-WG] Updated OAuth PoP documents
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Nov 2014 17:18:08 -0000

The token type is about the client RS binding.   It is up to the specs like to register the token types.   It may be possable for more than one binding to use the same token type, but that is up to them.

The term "token type" in retrospect may be slightly confusing in that the same AT format, may have multiple token types registered depending on the bindings.

By definition bearer an POP are mutually exclusive types of bindings.

The body hash is an option, but can be quite difficult for implementations in practice.  

John B.

On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin <> 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
> 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 <> 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 <>
>>>>> 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:
>>>>>>> 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
>>>>>> - 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 ?
>>>>>> 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
>>>>>> _______________________________________________
>>>>>> OAuth mailing list