Thanks Brian. I assume for a request which contains multiple "resource" parameters, if one or more of those are invalid, this should also cause an "invalid_resource" error?
How about the situation when the request includes a "scope" parameter, with one or more values which don't match the "resource(s)" (or vice versa) - how should the AS respond in that case? Have there been thoughts about specifying AS metadata parameters for publishing the supported resources and potentially their scope mappings? Mappings could be especially useful for clients to figure out which scopes belong to which resource, and prevent "invalid_resource" errors. Similarly, allowed "resources" in OAuth client metadata? About the statement > Scope, from Section 3.3 > <https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00#section-3.3> > of OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>], sometimes is > overloaded to convey the location or identity of the resource server, > however, doing so isn't always feasible or desirable. The rationale for the resource indicators spec (for new adopters) appears to rest on that statement. But what is the actual argument against overloading scopes, i.e. including the resource URL in the scope value ;) Readers of the spec will likely be pondering whether it's better to encode the resource URL / identifier in the scope, or use the separate "resource" parameter approach. I think we can greatly help them with a honest discussion of the pros & cons of the two approaches. And perhaps suggest how to migrate between the two. > Bearer tokens, currently the only defined type of OAuth > access token, allow any party in possession of a token to get access > to the associated resources. Worth mentioning token binding and mTLS here? Vladimir On 28/08/18 00:27, Brian Campbell wrote: > Sorry for the slow response Vladimir, > > It seemed worthwhile to have an error code that was more specific than > "invalid_request" to convey back to the client that there was an issue with > the value(s) it provided for the resource parameter - it's similar to > "invalid_scope" from RFC 6749 in that regard. Token exchange has something > similar for the resource parameter and I actually need to reconcile the > wording and naming in the resource indicators draft to better align with > that. I just haven't had a chance to get back into doing the spec edits on > this one yet. > > > On Wed, Aug 22, 2018 at 1:24 PM Vladimir Dzhuvinov <vladi...@connect2id.com> > wrote: > >> Hi Brian, >> >> 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". >> >> If the resource parameter is not an absolute URI, i.e. parsing of the >> value fails, wouldn't the existing general "invalid_request" error code be >> more appropriate? >> >> https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >> >> invalid_request >> The request is missing a required parameter, includes an >> invalid parameter value, includes a parameter more than >> once, or is otherwise malformed. >> >> Vladimir >> >> On 04/08/18 06:39, internet-dra...@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the IETF. >> >> Title : Resource Indicators for OAuth 2.0 >> Authors : Brian Campbell >> John Bradley >> Hannes Tschofenig >> Filename : draft-ietf-oauth-resource-indicators-00.txt >> Pages : 8 >> Date : 2018-08-03 >> >> 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. >> >> >> The IETF datatracker status page for this draft >> is:https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ >> >> There are also htmlized versions available >> at:https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-00 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP >> at:ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
