Re: [OAUTH-WG] Updated OAuth PoP documents

Sergey Beryozkin <> Mon, 10 November 2014 11:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 18A521A8A0D for <>; Mon, 10 Nov 2014 03:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pFSjF08qF1EP for <>; Mon, 10 Nov 2014 03:05:27 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A344D1A8A07 for <>; Mon, 10 Nov 2014 03:05:26 -0800 (PST)
Received: by with SMTP id d1so9975685wiv.15 for <>; Mon, 10 Nov 2014 03:05:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0Xh59ALJt3hlkHd/F6FSuhIvYPghOw7IuTvHbgfMJ6Y=; b=aNFK5wjJ9ikrc0v9yGWsKfpCOgUuVfzhMFlzxqeJ4bDA4x0nVlsm/F+WcoQPy2iNEf w3R3r1CTypkYLYxeyeInDvM3/nO3VN283pq8nszvUhTdcsy53Z2B2wcjHLuCUwFI4z/y fJVn+NSKOXvL33Ji5tAOPWzZcxKEo22gI+/ykiiQkBgs7mj/OUtnG4prLuMQ2jKPbeOY tFpz7U4T2cx3E+HRxTzlhBvcMPfSp7Ngg8pO2BagfY0y32Cx8/+fRBRXPTncwrVEGu6b txrYMvr0WKZX9DhmP/LcNMrOouGnPvzhTZA4rpgGOFIHWmfuZRj7pW0P65M1uagos6oA hjdQ==
X-Received: by with SMTP id ep9mr29313635wib.26.1415617521945; Mon, 10 Nov 2014 03:05:21 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id lp14sm11022859wic.20.2014. for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2014 03:05:21 -0800 (PST)
Message-ID: <>
Date: Mon, 10 Nov 2014 11:05:18 +0000
From: Sergey Beryozkin <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: John Bradley <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Mon, 10 Nov 2014 11:05:29 -0000

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