Re: [OAUTH-WG] aud, JAR, PoP key distro, etc. (was Re: IETF 93 OAuth WG Meeting Minutes)

Justin Richer <> Fri, 06 November 2015 23:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 854B11A92B7 for <>; Fri, 6 Nov 2015 15:07:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d4DpcEhG8FOz for <>; Fri, 6 Nov 2015 15:07:40 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 583C91AC3AC for <>; Fri, 6 Nov 2015 15:07:40 -0800 (PST)
X-AuditID: 1209190d-f79306d000006b70-ec-563d32baf3f2
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F8.19.27504.AB23D365; Fri, 6 Nov 2015 18:07:38 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id tA6N7bet030565; Fri, 6 Nov 2015 18:07:38 -0500
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id tA6N7XHm003378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Nov 2015 18:07:36 -0500
Date: Sat, 07 Nov 2015 08:07:31 +0900
Message-ID: <>
Importance: normal
From: Justin Richer <>
To: Brian Campbell <>, Hannes Tschofenig <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=""
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IR4hRV1t1lZBtmsGmhmcXq/zcZLZbuvMdq cfLtKzYHZo/Fm/azeSxZ8pPJ4+7RiywBzFFcNimpOZllqUX6dglcGZvmvWMpOBhYMbm/m7GB ca5/FyMHh4SAiUTjXZsuRk4gU0ziwr31bF2MXBxCAouZJL48nc4I4WxglDh/6zpU5iiTxJMr N1lAWlgEVCWe3rzGBGILC6RITJn0nxXE5hVwk2i4v4IdZAOngJBE1y4JkDAbUPn0NS1g5SIC mRJ/d21lBLGZgeJfFrxngmgVlDg58wkLRDxEYvb9o0wTGPlmIUnNQpKCsNUl/sy7xAxhK0pM 6X7IPgtoM7OAmsSyViVk4QWMbKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGC A1qSdwfju4NKhxgFOBiVeHg3/LAJE2JNLCuuzD3EKMnBpCTKu4DZNkyILyk/pTIjsTgjvqg0 J7X4EKMEB7OSCG+NElCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mC 950hUKNgUWp6akVaZk4JQpqJgxNkOA/Q8JsgNbzFBYm5xZnpEPlTjJpS4rzTQBICIImM0jy4 XlDCSSkVYATRl/qSBF4xigO9JMybC1LNA0xecFNeAS1gAlrgEGUDsqAkESEl1cCoVMLa4PzU qjdPKzeK3fr3ib8iXZsNy7Y5H8k8le34p+8Ak9d77QO1opmRMw4/fcyy30TKZi7TzvO75vif iHxyItxrkceikmjB5eL7UnoO/qxe9/1aXrLvDJ4Lbm1bvHe/LXA2mK4vsnr935B1s7wmWRov 2sMh1LFIc+HkgpobTNe91f76reBXYinOSDTUYi4qTgQAmvtvAhsDAAA=
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] aud, JAR, PoP key distro, etc. (was Re: IETF 93 OAuth WG Meeting Minutes)
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, 06 Nov 2015 23:07:43 -0000

I was considering preparing an "extended scopes" concept draft to define both a target parameter (what we're using "aud" for) as well as a temporal parameter, to sit beside scope which is more naturally an "extent of permission".
We need the audience bit for HEART, and I know others that do as well. 
I propose we define an extended scopes document like this to capture a couple categories like that. Good news is that we do have some implementation experience from both ping and Microsoft on this. 
-- Justin
/ Sent from my phone /

-------- Original message --------
From: Brian Campbell <> 
Date: 11/7/2015  7:56 AM  (GMT+09:00) 
To: Hannes Tschofenig <> 
Subject: [OAUTH-WG] aud, JAR, PoP key distro, etc. (was Re:  IETF 93 OAuth WG Meeting Minutes) 

That's right, sorry, there's not actually a conflict now as the PoP key distribution draft currently only uses the 'aud' parameter at the token endpoint. 

I just assume it will end up being used at the authorization endpoint eventually because the need to disambiguate where the token will be used isn't limited to the token endpoint (we do have this implicit thing). As John mentioned, we have used an 'aud' parameter (interpreted as a resource location) in our AS on both endpoints to allow the client to indicate where it intends to use the token it's asking for, which enables the AS to apply unique policy to that token for the given resource (it's not the exact same thing as PoP key distribution but conceptually similar). So I was confusing implementation experience with what was actually in the PoP key distribution draft.

That said, I do think that JAR should register JWT claims that it's likely to use in the Request Object as authorization endpoint parameters to avoid this kind of conflict. 

And I something like the 'aud' parameter is needed at both the token and authorization endpoints so  PoP key distribution should use a different name. Or this potential independent draft, which I do think has value. I was planning on proposing something that's based on similar parameters being worked on in token exchange - we're just not there quite yet. 

On Fri, Nov 6, 2015 at 6:03 AM, Hannes Tschofenig <> wrote:

        Brian also pointed out that there is a conflict with the PoP key

distribution draft that uses the 'aud' parameter. John noted that

currently the 'aud' parameter is used towards a different endpoint, used

as a query parameter, but it would probably be good to take this into

account now.

        Justin noted that there is general utility to indicate the audience.

Today people are forced to use the scope for WHAT, HOW and HOW LONG the

client wants to access a protected resource. The 'aud' describes the

WHAT aspect.  He suggested to take it a general utility extension that

is indepdent of the PoP document.

        Hannes added a remark that the 'aud' parameter / claim was a separate

document and then we added it to the PoP document.

        John said that we didn't had the wide-enough picture and we now

understand things better.