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

Discussion:

John Bradley

2016-03-20 21:17:53 UTC

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

Subject: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt
Date: March 20, 2016 at 8:14:14 PM GMT
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
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

Hannes Tschofenig

2016-03-21 07:09:02 UTC

Permalink

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

Post by John Bradley
We have had a number of discussions about splitting the audience part
of PoP key distribution out into its 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

*Subject: **New Version Notification for
draft-campbell-oauth-resource-indicators-00.txt*
*Date: *March 20, 2016 at 8:14:14 PM GMT
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
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-00.txt
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-00
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
<http://tools.ietf.org>.
The IETF Secretariat

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

John Bradley

2016-03-21 08:09:06 UTC

Permalink

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.

Post by Hannes Tschofenig
https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Hannes Tschofenig

2016-03-21 08:47:49 UTC

Permalink

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:***@ve7jtb.com]
Sent: 21 March 2016 09:09
To: Hannes Tschofenig
Cc: <***@ietf.org>; Hannes Tschofenig
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt

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.

Post by Hannes Tschofenig
https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00

Post by John Bradley
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

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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.

Brian Campbell

2016-03-22 13:07:05 UTC

Permalink

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 <

Post by Hannes Tschofenig
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-----
Sent: 21 March 2016 09:09
To: Hannes Tschofenig
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
draft-campbell-oauth-resource-indicators-00.txt
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 <
https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00

discussion.

Post by John Bradley
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

https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-00.txt
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-00

Post by John Bradley

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
<http://tools.ietf.org>.
The IETF Secretariat

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Brian Campbell

2016-03-22 12:48:53 UTC

Permalink

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.

Post by John Bradley
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.