Sorry again for the slow response Vladimir, I've tried to respond inline below.
On Sat, Sep 1, 2018 at 2:47 AM Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > 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? > As I mentioned before, Token Exchange has (and registers) a similar parameter and error code and I need to reconcile the wording and naming in the resource indicators draft to better align with that because it's ultimately the same parameter with just a more generalized usage in this draft. In particular the error code there is "invalid_target" and I think that it would be appropriate for issues with the resource parameter as well as for problematic combinations of resource and scope. And the "error_description" is always available to provide a more human meaningful explanation of the problem. > 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. > There was quite a bit of discussion around this kind of thing when the draft was introduced and the general consensuses was not to have AS metadata about resources. There are ASs that don't know all the resources or can't know or don't want to have to know. And more generally it just doesn't scale well. > Similarly, allowed "resources" in OAuth client metadata? > The client metadata side hasn't really been discussed as far as I know. But my inclination would similarly be to not define any new 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. > I can look to expand the discussion some. But I'm honestly not sure what else to say or is appropriate to say. It's a complex and somewhat loaded topic. It's not exactly related but makes me think of this recent blog from Vittorio about scopes <https://auth0.com/blog/on-the-nature-of-oauth2-scopes/>. Anyway, if you have some concrete suggestions here, please share them. > > 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? > > Yeah, that text was written before the MTLS draft existed and should be updated to more accurately reflect the current situation and options. Thanks for pointing that one out. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
