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
On 21/03/16 23:15, Phil Hunt wrote:
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
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Mar 21, 2016, at 10:41 AM, Brian Campbell
<bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>> wrote:
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-dra...@ietf.org <mailto:internet-dra...@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 <hannes.tschofe...@gmx.net
<mailto:hannes.tschofe...@gmx.net>>, Hannes Tschofenig
<hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>>, Brian
Campbell <brian.d.campb...@gmail.com
<mailto:brian.d.campb...@gmail.com>>, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@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
<http://tools.ietf.org/>.
The IETF Secretariat
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
