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

[Brian Campbell]

Very minor update to this draft before the deadline that moves Hannes from
Acknowledgements to Authors in acknowledgment of his similar work a few
years ago. Also fleshed out the IANA section with the formal registration
requests.


---------- Forwarded message ----------
From: <internet-***@ietf.org>
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for
draft-campbell-oauth-resource-indicators-01.txt
To: Hannes Tschofenig <***@gmx.net>, Hannes Tschofenig <
***@gmx.net>, Brian Campbell <***@gmail.com>,
John Bradley <***@ve7jtb.com>



A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name: draft-campbell-oauth-resource-indicators
Revision: 01
Title: Resource Indicators for OAuth 2.0
Document date: 2016-03-21
Group: Individual Submission
Pages: 8
URL:
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
Status:
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
Htmlized:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01

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

[Phil Hunt]

What about server processing rules and error conditions? The client passes the resource in with every request. What happens if it sends a bad URL. I see the registration for invalid_resource, but I see no processing logic for the server that describes when that is returned. I’ll assume that is TBD.

The draft seems more finer grained than with bound configuration approach. It suggests that the client will make a different URL request for each resource URL. This could lead to a lot of unnecessary authorizations. I think we still have to resolve the audience to resource relationship problem and just how much detail the AS service needs to know.

I note that we have a similar issue with bound config on how granular resource URL processing is needed. My main goal is for config to validate the domain name only as a major improvement as we just need to make sure the client is talking to a valid server and not a MITM proxy.

Finally, there is the question of optionality (in order to have backwards compatibility for static clients). If resource is optional, than how do we deal with dynamic clients that simply don’t both to use the resource parameter?

We’re depending on client developers taking an extra step to provide the resource parameter. Maybe optionality for resource url becomes part of the client_id registration? In contrast, config discovery is brand new, so making validation required is not such a big deal as static clients wouldn’t use discovery.

Another failure condition both drafts should consider:
* when an authorization, token, or resource endpoint starts to fail, should the client fall back to discovery to re-verify configuration? If so, on what errors? A valid usecase would be a service provider deciding to re-configure its services naturally over time.
* what are the issues when an endpoint that was part of configuration issues a re-direct? There are good and bad scenarios (e.g. to a specific cluster node), a resource that was relocated, or a hacked service that wants to steal tokens. In these cases, should the client re-validate the new resource URI either using this draft or the bound config method?

On a positive note, unrelated to security, there have been a lot of inquiries over the years about how to authorize against on user-owned resources. E.g. How can I ask for authorizations to Brian’s github project? I think this is worth discussing. Weighing the security and functionality needs would be a worthwhile discussion in BA.

Phil

@independentid

Very minor update to this draft before the deadline that moves Hannes from Acknowledgements to Authors in acknowledgment of his similar work a few years ago. Also fleshed out the IANA section with the formal registration requests.
---------- Forwarded message ----------
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.
Name: draft-campbell-oauth-resource-indicators
Revision: 01
Title: Resource Indicators for OAuth 2.0
Document date: 2016-03-21
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt <https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt>
Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ <https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/>
Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 <https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01>
Diff: https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01 <https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01>
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

[Sergey Beryozkin]

Hi

Is there any reason why 'resource' parameter can not be named 'aud' or
'audience' ?

The text says "AS should audience restrict" the access token and that a
token 'aud' property may be equal to this "resource" value.

I guess 'audience' is a pure access token property, while as far as
client is concerned, it is a 'resource', but I wonder if it would be a
bit simpler if only a single property was used.

It also might make sense to mention that the clients can have 'resource'
values associated with them at the registration time - this can be done
by admins, and the client applications will not have to be configured to
send 'resource' given that AS already knows about the resource restrictions.

Cheers, Sergey

Post by Phil Hunt
What about server processing rules and error conditions? The client
passes the resource in with every request. What happens if it sends a
bad URL. I see the registration for invalid_resource, but I see no
processing logic for the server that describes when that is returned.
I’ll assume that is TBD.
The draft seems more finer grained than with bound configuration
approach. It suggests that the client will make a different URL request
for each resource URL. This could lead to a lot of unnecessary
authorizations. I think we still have to resolve the audience to
resource relationship problem and just how much detail the AS service
needs to know.
I note that we have a similar issue with bound config on how granular
resource URL processing is needed. My main goal is for config to
validate the domain name only as a major improvement as we just need to
make sure the client is talking to a valid server and not a MITM proxy.
Finally, there is the question of optionality (in order to have
backwards compatibility for static clients). If resource is optional,
than how do we deal with dynamic clients that simply don’t both to use
the resource parameter?
We’re depending on client developers taking an extra step to provide the
resource parameter. Maybe optionality for resource url becomes part of
the client_id registration? In contrast, config discovery is brand new,
so making validation required is not such a big deal as static clients
wouldn’t use discovery.
* when an authorization, token, or resource endpoint starts to fail,
should the client fall back to discovery to re-verify configuration? If
so, on what errors? A valid usecase would be a service provider
deciding to re-configure its services naturally over time.
* what are the issues when an endpoint that was part of configuration
issues a re-direct? There are good and bad scenarios (e.g. to a specific
cluster node), a resource that was relocated, or a hacked service that
wants to steal tokens. In these cases, should the client re-validate
the new resource URI either using this draft or the bound config method?
*On a positive note, unrelated to security, there have been a lot of
inquiries over the years about how to authorize against on user-owned
resources. E.g. How can I ask for authorizations to Brian’s github
project? I think this is worth discussing. Weighing the security and
functionality needs would be a worthwhile discussion in BA.*
Phil
@independentid
www.independentid.com <http://www.independentid.com>

On Mar 21, 2016, at 10:41 AM, Brian Campbell
Very minor update to this draft before the deadline that moves Hannes
from Acknowledgements to Authors in acknowledgment of his similar work
a few years ago. Also fleshed out the IANA section with the formal
registration requests.
---------- Forwarded message ----------
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for
draft-campbell-oauth-resource-indicators-01.txt
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.
Name: draft-campbell-oauth-resource-indicators
Revision: 01
Title: Resource Indicators for OAuth 2.0
Document date: 2016-03-21
Group: Individual Submission
Pages: 8
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01
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

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

[Brian Campbell]

'aud' can't be used b/c it conflicts with the (yet to be registered) 'aud'
claim/parameter in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq and
JWS/E requests in Connect (honestly, I'd like to use aud because we've
already done so in product but I don't think it works given the spec
landscape). Also, as you mention, 'resource' is what the client is
concerned with accessing. So the name is more representative of what it
actually is.

Yes, some more discussion of default or legacy behaviors based on config or
policy or registration is probably warranted. I suppose that begs the
question of if a OAuth Dynamic Client Registration Metadata parameter
should be defined too?

Post by Sergey Beryozkin
Hi
Is there any reason why 'resource' parameter can not be named 'aud' or
'audience' ?
The text says "AS should audience restrict" the access token and that a
token 'aud' property may be equal to this "resource" value.
I guess 'audience' is a pure access token property, while as far as client
is concerned, it is a 'resource', but I wonder if it would be a bit simpler
if only a single property was used.
It also might make sense to mention that the clients can have 'resource'
values associated with them at the registration time - this can be done by
admins, and the client applications will not have to be configured to send
'resource' given that AS already knows about the resource restrictions.
Cheers, Sergey

Post by Phil Hunt
What about server processing rules and error conditions? The client
passes the resource in with every request. What happens if it sends a
bad URL. I see the registration for invalid_resource, but I see no
processing logic for the server that describes when that is returned.
I’ll assume that is TBD.
The draft seems more finer grained than with bound configuration
approach. It suggests that the client will make a different URL request
for each resource URL. This could lead to a lot of unnecessary
authorizations. I think we still have to resolve the audience to
resource relationship problem and just how much detail the AS service
needs to know.
I note that we have a similar issue with bound config on how granular
resource URL processing is needed. My main goal is for config to
validate the domain name only as a major improvement as we just need to
make sure the client is talking to a valid server and not a MITM proxy.
Finally, there is the question of optionality (in order to have
backwards compatibility for static clients). If resource is optional,
than how do we deal with dynamic clients that simply don’t both to use
the resource parameter?
We’re depending on client developers taking an extra step to provide the
resource parameter. Maybe optionality for resource url becomes part of
the client_id registration? In contrast, config discovery is brand new,
so making validation required is not such a big deal as static clients
wouldn’t use discovery.
* when an authorization, token, or resource endpoint starts to fail,
should the client fall back to discovery to re-verify configuration? If
so, on what errors? A valid usecase would be a service provider
deciding to re-configure its services naturally over time.
* what are the issues when an endpoint that was part of configuration
issues a re-direct? There are good and bad scenarios (e.g. to a specific
cluster node), a resource that was relocated, or a hacked service that
wants to steal tokens. In these cases, should the client re-validate
the new resource URI either using this draft or the bound config method?
*On a positive note, unrelated to security, there have been a lot of
inquiries over the years about how to authorize against on user-owned
resources. E.g. How can I ask for authorizations to Brian’s github
project? I think this is worth discussing. Weighing the security and
functionality needs would be a worthwhile discussion in BA.*
Phil
@independentid
www.independentid.com <http://www.independentid.com>
On Mar 21, 2016, at 10:41 AM, Brian Campbell

Post by Brian Campbell
Very minor update to this draft before the deadline that moves Hannes
from Acknowledgements to Authors in acknowledgment of his similar work
a few years ago. Also fleshed out the IANA section with the formal
registration requests.
---------- Forwarded message ----------
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for
draft-campbell-oauth-resource-indicators-01.txt
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.
Name: draft-campbell-oauth-resource-indicators
Revision: 01
Title: Resource Indicators for OAuth 2.0
Document date: 2016-03-21
Group: Individual Submission
Pages: 8
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01
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

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

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

[Brian Campbell]

I don't consider this draft to be a direct alternative to the bound config
thing. It aims to fill a need that the WG has discussed several times
previously. It happens to also facilitate getting audience restrictions
into ATs, which address the concerns about a bad RS using an AT at a good
RS that seem to have surfaced recently (and some have gone so far as to say
isn't a 'real problem' at this time). AFAICT, bound config was put forth as
commentary or an alternative to "OAuth 2.0 Authorization Server Discovery
Metadata" that tries to check the legitimacy of an RS with webfinger.
Though, to be honest, I don't really understand what bound config solves.

The client provides the resource parameter to the token endpoint to
indicate what RS it wants a token for. Or to the authorization endpoint for
implicit (when an AT is returned as an authorization response parameter).
There shouldn't be a a need for unnecessary authorizations in most cases.

The audience to resource relationship is determined by the AS and RSs and
their deployment relationship. Pretty much how it is today. The resource
parameter just gives the client a tool to communicate the RS to the AS.

Backwards compatibility and optionality do need to be taken into account.
It's an extension. How migration and enforcement will be handled will be
policy and implementation decisions. That's just the state of things with
OAuth.

The resource parameter is available to all clients and doesn't rely on
discovery or metadata or registration.

The error condition is described in the draft as follows. Is there
something specific you believe should be addressed?

'If the
authorization server fails to parse the provided value or does not
consider the resource server acceptable, it MUST reject the
request and provide an error response with the error code
"invalid_resource".'

Post by Phil Hunt
What about server processing rules and error conditions? The client
passes the resource in with every request. What happens if it sends a bad
URL. I see the registration for invalid_resource, but I see no processing
logic for the server that describes when that is returned. I’ll assume
that is TBD.
The draft seems more finer grained than with bound configuration
approach. It suggests that the client will make a different URL request
for each resource URL. This could lead to a lot of unnecessary
authorizations. I think we still have to resolve the audience to resource
relationship problem and just how much detail the AS service needs to know.
I note that we have a similar issue with bound config on how granular
resource URL processing is needed. My main goal is for config to validate
the domain name only as a major improvement as we just need to make sure
the client is talking to a valid server and not a MITM proxy.
Finally, there is the question of optionality (in order to have backwards
compatibility for static clients). If resource is optional, than how do we
deal with dynamic clients that simply don’t both to use the resource
parameter?
We’re depending on client developers taking an extra step to provide the
resource parameter. Maybe optionality for resource url becomes part of the
client_id registration? In contrast, config discovery is brand new, so
making validation required is not such a big deal as static clients
wouldn’t use discovery.
* when an authorization, token, or resource endpoint starts to fail,
should the client fall back to discovery to re-verify configuration? If
so, on what errors? A valid usecase would be a service provider deciding
to re-configure its services naturally over time.
* what are the issues when an endpoint that was part of configuration
issues a re-direct? There are good and bad scenarios (e.g. to a specific
cluster node), a resource that was relocated, or a hacked service that
wants to steal tokens. In these cases, should the client re-validate the
new resource URI either using this draft or the bound config method?
*On a positive note, unrelated to security, there have been a lot of
inquiries over the years about how to authorize against on user-owned
resources. E.g. How can I ask for authorizations to Brian’s github
project? I think this is worth discussing. Weighing the security and
functionality needs would be a worthwhile discussion in BA.*
Phil
@independentid
www.independentid.com
Very minor update to this draft before the deadline that moves Hannes from
Acknowledgements to Authors in acknowledgment of his similar work a few
years ago. Also fleshed out the IANA section with the formal registration
requests.
---------- Forwarded message ----------
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for
draft-campbell-oauth-resource-indicators-01.txt
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.
Name: draft-campbell-oauth-resource-indicators
Revision: 01
Title: Resource Indicators for OAuth 2.0
Document date: 2016-03-21
Group: Individual Submission
Pages: 8
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Torsten Lodderstedt]

Hi Brian,

did you intentionally omit scope values in your example requests? I would like to know what you envision to be the relationshop between scope and resource.

As you draft says, we today use scope values to indicate to the AS, which ressource servers the clients wants to access. I think we nearly exclusively use it for that purpose and only seldomly to request certain access rights. One of the advantages is, we can request access to multiple resource servers simple by putting multiple scope values into the scope parameter. Will this be possible with the extension you are proposing?

Best regards,
Torsten.

Very minor update to this draft before the deadline that moves Hannes from Acknowledgements to Authors in acknowledgment of his similar work a few years ago. Also fleshed out the IANA section with the formal registration requests.
---------- Forwarded message ----------
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.
Name: draft-campbell-oauth-resource-indicators
Revision: 01
Title: Resource Indicators for OAuth 2.0
Document date: 2016-03-21
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

Sorry for the slow response, Torsten, I was on vacation last week with my
family.

The omission of scope values in the example requests wasn't really
intentional so much as just an initial desire to have a minimal amount of
stuff in the examples. Adding a scope parameter to the example
authorization request (Figure 1) would probably be a good thing to do. I'll
make a note to do so.

As far as the relationship between scope and resource. Scope is *what*
access is being requested/granted. And resource is about *where* a
particular access token will be used. I envision resource as allowing for
scope to

Note that, as currently written anyway, resource is unlike scope in that
it's not something that the end-user approves or denies access to and it's
not something that is persisted with the grant. It only informs the access
token being requested at the time. So it'd be used at the token endpoint
when getting an access token. And only at the authorization endpoint when
an access token will come back directly in the authorization response
(implicit flows).

Currently, yes, multiple resources are allowed by the draft to indicate
multiple RSs. Though there's a note in there questioning it because it
complicates things in some situations where different token content or
encryption is needed for different RSs that are asked for in the same
request.

Post by Torsten Lodderstedt
Hi Brian,
did you intentionally omit scope values in your example requests? I would
like to know what you envision to be the relationshop between scope and
resource.
As you draft says, we today use scope values to indicate to the AS, which
ressource servers the clients wants to access. I think we nearly
exclusively use it for that purpose and only seldomly to request certain
access rights. One of the advantages is, we can request access to multiple
resource servers simple by putting multiple scope values into the scope
parameter. Will this be possible with the extension you are proposing?
Best regards,
Torsten.
Very minor update to this draft before the deadline that moves Hannes from
Acknowledgements to Authors in acknowledgment of his similar work a few
years ago. Also fleshed out the IANA section with the formal registration
requests.
---------- Forwarded message ----------
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for
draft-campbell-oauth-resource-indicators-01.txt
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.
Name: draft-campbell-oauth-resource-indicators
Revision: 01
Title: Resource Indicators for OAuth 2.0
Document date: 2016-03-21
Group: Individual Submission
Pages: 8
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[t***@lodderstedt.net]

Hi Brian,

I assume resource server ids or URIs to be a names namespace for scope values or that scope values are be bound to certain resource servers. It seems you have less coupling in mind?

Best regards,
Torsten.

Sent by MailWise – See your emails as clean, short chats.

-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt

Post by Brian Campbell
Sorry for the slow response, Torsten, I was on vacation last week with my
family.
The omission of scope values in the example requests wasn't really
intentional so much as just an initial desire to have a minimal amount of
stuff in the examples. Adding a scope parameter to the example
authorization request (Figure 1) would probably be a good thing to do. I'll
make a note to do so.
As far as the relationship between scope and resource. Scope is *what*
access is being requested/granted. And resource is about *where* a
particular access token will be used. I envision resource as allowing for
scope to
Note that, as currently written anyway, resource is unlike scope in that
it's not something that the end-user approves or denies access to and it's
not something that is persisted with the grant. It only informs the access
token being requested at the time. So it'd be used at the token endpoint
when getting an access token. And only at the authorization endpoint when
an access token will come back directly in the authorization response
(implicit flows).
Currently, yes, multiple resources are allowed by the draft to indicate
multiple RSs. Though there's a note in there questioning it because it
complicates things in some situations where different token content or
encryption is needed for different RSs that are asked for in the same
request.

Post by Torsten Lodderstedt
Hi Brian,
did you intentionally omit scope values in your example requests? I would
like to know what you envision to be the relationshop between scope and
resource.
As you draft says, we today use scope values to indicate to the AS, which
ressource servers the clients wants to access. I think we nearly
exclusively use it for that purpose and only seldomly to request certain
access rights. One of the advantages is, we can request access to multiple
resource servers simple by putting multiple scope values into the scope
parameter. Will this be possible with the extension you are proposing?
Best regards,
Torsten.
Very minor update to this draft before the deadline that moves Hannes from
Acknowledgements to Authors in acknowledgment of his similar work a few
years ago. Also fleshed out the IANA section with the formal registration
requests.
---------- Forwarded message ----------
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for
draft-campbell-oauth-resource-indicators-01.txt
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.
Name: draft-campbell-oauth-resource-indicators
Revision: 01
Title: Resource Indicators for OAuth 2.0
Document date: 2016-03-21
Group: Individual Submission
Pages: 8
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[John Bradley]

At this point we are not considering changing the vague nature of scopes.

A scope might still grant permission at the API level or finer grained.

With things like the FIRE health record API there are standard scopes so I am assuming that if the client wants scope x, y ,z for health provider A & B it would ask for 3 scopes and two resources in the authorization request. The user might not grant all scopes doe all endpoints.

When the client asks for a AT for RS A that might have different scopes than the one for RS B.

If the client wants to ask for different scopes for different resources then it would need to do two authorization requests.

Creating a request that could say give me x & y for A and z for B is probably farther than we want to go.

It is a interesting point for the WG to consider.

John B.

Post by Torsten Lodderstedt
Hi Brian,
I assume resource server ids or URIs to be a names namespace for scope values or that scope values are be bound to certain resource servers. It seems you have less coupling in mind?
Best regards,
Torsten.
Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails as clean, short chats.
-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
Sorry for the slow response, Torsten, I was on vacation last week with my family.
The omission of scope values in the example requests wasn't really intentional so much as just an initial desire to have a minimal amount of stuff in the examples. Adding a scope parameter to the example authorization request (Figure 1) would probably be a good thing to do. I'll make a note to do so.
As far as the relationship between scope and resource. Scope is *what* access is being requested/granted. And resource is about *where* a particular access token will be used. I envision resource as allowing for scope to
Note that, as currently written anyway, resource is unlike scope in that it's not something that the end-user approves or denies access to and it's not something that is persisted with the grant. It only informs the access token being requested at the time. So it'd be used at the token endpoint when getting an access token. And only at the authorization endpoint when an access token will come back directly in the authorization response (implicit flows).
Currently, yes, multiple resources are allowed by the draft to indicate multiple RSs. Though there's a note in there questioning it because it complicates things in some situations where different token content or encryption is needed for different RSs that are asked for in the same request.
Hi Brian,
did you intentionally omit scope values in your example requests? I would like to know what you envision to be the relationshop between scope and resource.
As you draft says, we today use scope values to indicate to the AS, which ressource servers the clients wants to access. I think we nearly exclusively use it for that purpose and only seldomly to request certain access rights. One of the advantages is, we can request access to multiple resource servers simple by putting multiple scope values into the scope parameter. Will this be possible with the extension you are proposing?
Best regards,
Torsten.

Very minor update to this draft before the deadline that moves Hannes from Acknowledgements to Authors in acknowledgment of his similar work a few years ago. Also fleshed out the IANA section with the formal registration requests.
---------- Forwarded message ----------
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.
Name: draft-campbell-oauth-resource-indicators
Revision: 01
Title: Resource Indicators for OAuth 2.0
Document date: 2016-03-21
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt <https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt>
Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ <https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/>
Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 <https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01>
Diff: https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01 <https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01>
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 <https://www.ietf.org/mailman/listinfo/oauth>

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