Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt

From: John Bradley <[email-masked]>
Date: Sun, 20 Mar 2016 21:17:53 +0000

We have had a number of discussions  about splitting the audience part of PoP key distribution out into it’s own draft

Phil also requested  a draft on how I propose propose that proper audiencing of access tokens can mitigate against the threat of bearer access token leakage.

In response Brian Campbell and I have created a short 00 draft on how the client can specify the resource that it is requesting a token for without overloading scopes.

I hope that this will make some of the issues clearer for our discussion.

As Justin pointed out we may also want to separate out offline access and some other common things from scope as well.  This is intended to start the discussion not preclude other discussions around how to reduce the overloading of scope.

Regards
John Bradley

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt
> Date: March 20, 2016 at 8:14:14 PM GMT
> To: "Brian Campbell" <[email-masked]>, "John Bradley" <[email-masked]>
> 
> 
> A new version of I-D, draft-campbell-oauth-resource-indicators-00.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
> 
> Name:		draft-campbell-oauth-resource-indicators
> Revision:	00
> Title:		Resource Indicators for OAuth 2.0
> Document date:	2016-03-20
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
> Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-00
> 
> 
> Abstract:
>   This straw-man specification defines an extension to The OAuth 2.0
>   Authorization Framework that enables the client and authorization
>   server to more explicitly to communicate about the protected
>   resource(s) to be accessed.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Mar 2016 08:09:02 +0100

FWIW: I also worth I wrote a draft a while ago about this topic:
https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00

On 03/20/2016 10:17 PM, John Bradley wrote:
> We have had a number of discussions  about splitting the audience part
> of PoP key distribution out into it’s own draft
> 
> Phil also requested  a draft on how I propose propose that proper
> audiencing of access tokens can mitigate against the threat of bearer
> access token leakage.
> 
> In response Brian Campbell and I have created a short 00 draft on how
> the client can specify the resource that it is requesting a token for
> without overloading scopes.
> 
> As Justin pointed out we may also want to separate out offline access
> and some other common things from scope as well.  This is intended to
> start the discussion not preclude other discussions around how to reduce
> the overloading of scope.
> 
> Regards
> John Bradley
> 
> 
> 
>> Begin forwarded message:
>>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for
>> draft-campbell-oauth-resource-indicators-00.txt*
>> *Date: *March 20, 2016 at 8:14:14 PM GMT
>> *To: *"Brian Campbell" <[email-masked]
>> <mailto:[email-masked]>>, "John Bradley"
>> <[email-masked] <mailto:[email-masked]>>
>>
>>
>> Name:draft-campbell-oauth-resource-indicators
>> Revision:00
>> Title:Resource Indicators for OAuth 2.0
>> Document date:2016-03-20
>> Group:Individual Submission
>> Pages:7
>> URL:
>>            https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-00.txt
>> Status:
>>         https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>> Htmlized:
>>       https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-00
>>
>>
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Bradley <[email-masked]>
Date: Mon, 21 Mar 2016 08:09:06 +0000

Thanks Hannes

We should merge them they are very similar.

We made a distinction between the resource URI and the audience to try and avoid some confusion about overloading the term audience.

We also covered the security considerations around user hosted content and being specific about the resource to avoid leakage.

We were less concerned about talking about key material, or the type of token.

We wanted to be able to show the WG that audience restricting AT has different and I argue better security properties than doing out of band discovery of the resource to try and stop AT leakage.

John B.

> On Mar 21, 2016, at 7:09 AM, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Mar 2016 08:47:49 +0000

Hi John,

We certainly had some confusion about what is the best possible term for the client to indicate to the resource server what RS it wants to access and for the AS to say what RS the client is allowed to access.

For me the inband approach (either by carrying the information in the AT or by obtaining the information via token introspection in those cases where the AT is actually a reference rather than a self-contained token) is a useful approach that should have actually provided by the OAuth spec from the first day onwards.

The reason draft-tschofenig-oauth-audience-00 was not advanced at that time was that the group (at the time) wanted to include the functionality in the PoP token work, as you are very well aware of. In the meanwhile it seems that the group had again changed their mind and wants to rather progress the work as an independent doc.

Ciao
Hannes

-----Original Message-----
From: John Bradley [mailto:[email-masked]]
Sent: 21 March 2016 09:09
To: Hannes Tschofenig
Cc: <[email-masked]>; Hannes Tschofenig
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt

Thanks Hannes

John B.

>> of PoP key distribution out into it's own draft
>>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 22 Mar 2016 06:48:53 -0600

Indeed, Justin has also suggested a temporal parameter in the past. That's
not captured currently in this draft but that's not intended to preclude
doing so in future revisions, if we can get some more concrete
proposals/discussions around what that would look like.

In our implementation, the temporal nature of tokens and grants is driven
from configuration and policy rather than at the client's request, so I
don't really have experience with how a run-time parameter might look or
work.

On Sun, Mar 20, 2016 at 3:17 PM, John Bradley <[email-masked]> wrote:

>
> As Justin pointed out we may also want to separate out offline access and
> some other common things from scope as well.  This is intended to start the
> discussion not preclude other discussions around how to reduce the
> overloading of scope.
>
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 22 Mar 2016 07:07:05 -0600

I agree that the in-band approach, and the pieces needed to facilitate it,
probably should have been provided by the OAuth spec from the beginning.
There is both security and basic functional value in it. This draft aims to
close that gap.

There has been, and likely will continue to be, some confusion on the
terms/names. As John said, we elected to use the name 'resource' for the
parameter to try and avoid further overloading the term audience.

FWIW, we currently have support for a similar parameter that enables the
appropriate access token policy to be used based on the target resource
indicated by the client. We went with 'aud' based on hope/expectation that
draft-ietf-oauth-pop-key-distribution's use of the parameter would get
picked up. But 'resource' feels like a more natural name for it. And there
are potential name conflicts with 'aud' and draft-ietf-oauth-jwsreq. So
we'll have some compatibility and migration issues to deal with.

On Mon, Mar 21, 2016 at 2:47 AM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi John,
>
> We certainly had some confusion about what is the best possible term for
> the client to indicate to the resource server what RS it wants to access
> and for the AS to say what RS the client is allowed to access.
>
> For me the inband approach (either by carrying the information in the AT
> or by obtaining the information via token introspection in those cases
> where the AT is actually a reference rather than a self-contained token) is
> a useful approach that should have actually provided by the OAuth spec from
> the first day onwards.
>
> The reason draft-tschofenig-oauth-audience-00 was not advanced at that
> time was that the group (at the time) wanted to include the functionality
> in the PoP token work, as you are very well aware of. In the meanwhile it
> seems that the group had again changed their mind and wants to rather
> progress the work as an independent doc.
>
> Ciao
> Hannes
>
>
> Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
> draft-campbell-oauth-resource-indicators-00.txt
>
> Thanks Hannes
>
> We made a distinction between the resource URI and the audience to try and
> avoid some confusion about overloading the term audience.
>
> We also covered the security considerations around user hosted content and
> being specific about the resource to avoid leakage.
>
> We wanted to be able to show the WG that audience restricting AT has
> different and I argue better security properties than doing out of band
> discovery of the resource to try and stop AT leakage.
>
> John B.
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>