Re: [OAUTH-WG] Updated OAuth PoP documents

John Bradley <> Fri, 07 November 2014 21:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 285541A1AB4 for <>; Fri, 7 Nov 2014 13:28:12 -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 PX-F0E4Kg4XL for <>; Fri, 7 Nov 2014 13:28:10 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3351F1A1A2A for <>; Fri, 7 Nov 2014 13:28:10 -0800 (PST)
Received: by with SMTP id r5so3208444qcx.33 for <>; Fri, 07 Nov 2014 13:28:09 -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=qmLixdl3cNRn+pdLsAcZZwAn3vAuhcMl31hkd6GZggw=; b=d9C0ll+pEmp0qVlTeExE9xecaeYmFKJT3RckneyHekDW2X9nYyQJ9QLjpHCldMa1pn JE2bdvLXw8v+XbCssUNXh7njlTHCIO+EnWFkX2bDiXygkXPm4ZRp5fqMgTY9VvusbfMq Zb4Hk5D7Jm+4ZCCvQ5jndLlBzXOwllt97bMVl0B8fnYu7k6TmjHbxNAsZ1G6ZBS3O0Mh wQwcOrqBLq1j22B+LdKQ9UY+ZxIpSU92Yvvn0bmYPabjuRWPazNrpDgtjWCeKw+3KKbZ wc74NsIAHotcLbmDNBXKC9w6AjTi0v+rv/hyQ8T3Ns3PcoU3imSEw1f5CyUY5zIwaXuM 6SMQ==
X-Gm-Message-State: ALoCoQlE5tivpH1YmBed9umZ3QuB4FGoMNL92niiE18DUS8s3USl9FS6HevrljnWpeHLfKQVLBlt
X-Received: by with SMTP id e10mr20601319qgf.71.1415395689353; Fri, 07 Nov 2014 13:28:09 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id k4sm9335646qaf.0.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 13:28:09 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <>
In-Reply-To: <>
Date: Fri, 07 Nov 2014 18:27:52 -0300
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: Fri, 07 Nov 2014 21:28:12 -0000

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

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

Requiring encryption is probably overkill.

John B.

> Thanks, Sergey
>> Ciao
>> Hannes
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list