Adopt Resource Indicators or similar system to limit token access to resources

[dshanske]

https://datatracker.ietf.org/doc/html/rfc8707 is the resource indicator specification

Suggest, unlike the specification, that resource optionally be in the return...that would allow an endpoint not requesting any specific resource to be told what the endpoint opted to grant.

[jamietanna]

I currently support this, with tokens issued the resource=https://www-api.jvt.me/ which, following RFC8707 allows redemption at any of the sub-paths of that resource such as https://www-api.jvt.me/micropub.

(Originally published at: https://www.jvt.me/mf2/2021/07/eheqe/)

[dshanske]

I am in favor of returning resource as the origin parameter. If we match the token introspection rfc, they use aud. I'm not sure why a parameter should change from submission to return. But worth considering re compatibility

[dshanske]

The reason this isn't being discussed in the Ticket Auth proposal.. https://indieweb.org/IndieAuth_Ticket_Auth is that the question of protected resources is an IndieAuth level question. Ticket Auth, AutoAuth, etc as extensions, dictate how tokens can be given to external parties for resources, not how resources work.

[dshanske]

Elements of RFC8707 to adopt...

• resource - Indicates the target service or resource to which access is being requested. Its value MUST be an absolute URI, as specified by Section 4.3 of [RFC3986]. The URI MUST NOT include a fragment component. It SHOULD NOT include a query component, but it is recognized that there are cases that make a query component a useful and necessary part of the resource parameter, such as when one or more query parameters are used to scope requests to an application. The "resource" parameter URI value is an identifier representing the identity of the resource, which MAY be a locator that corresponds to a network-addressable location where the target resource is hosted. Multiple "resource" parameters MAY be used to indicate that the requested token is intended to be used at multiple resources.

Suggest that, since IndieAuth is based on the idea of URL as identity, that resources MUST be network-addressable locations, as opposed to MAY.

• error response invalid_target should be added with no modification
• When the "resource" parameter is used in an authorization request to the authorization endpoint, it indicates the identity of the
  protected resource(s) to which access is being requested.
• If the client omits the "resource" parameter when requesting authorization, the authorization server MAY process the request with no specific resource or by using a predefined default resource value. Alternatively, the authorization server MAY require clients to specify the resource(s) they intend to access and MAY fail requests that omit the parameter with an "invalid_target" error. The authorization server might use this data to inform the user about the resources the client is going to access on their behalf, to apply policy (e.g., refuse the request due to unknown resources), and to determine the set of resources that can be used in subsequent access token requests.

This suggestion begs the question, should you be able to query this somewhere...#43 ?

• When the "resource" parameter is used on an access token request made to the token endpoint, for all grant types, it indicates the target service or protected resource where the client intends to use the requested access token.
• The indicated access token response in RFC8707 does not include the resource. Since the IndieAuth token endpoint is able to respond as part of token verification, it should.
• One of the listed security concerns involves multi-user sites. In the case of these sites, the same considerations would apply. That someone should not be able to issue a token with a resource that they have no permission to issue for.

[martymcguire]

I have a few questions about how this would be used:

1. The language so far in Introduce Resource Indicators #96 covers how an IndieAuth client can include resources in an authorization request, but doesn't mention any mechanism for discovery of resources. Some examples:

• would a micropub client need to request the micropub endpoint as a resource?
  • how about the micropub media endpoint? note that a micropub client can only learn whether a micropub media endpoint exists by making an authorized ?q=config request to the micropub endpoint. would the client then need to make a new authorization round trip to get a token with that added resource?
• would a micropub client also need to request resources for the URLs or paths where it wants to create new posts, or update or delete existing posts?
• i see a lot of discussion around resource for TicketAuth, but I'm not clear on how discovery works here, either. like, how would a feed reader learn which feed URLs it could or should include in a resource ask?

2. What are the compatibility stories for legacy indieauth clients and endpoints? particularly as either/both scope and resource are supported. For example, as an author of a micropub endpoint, do i allow tokens with scope-but-not-resource until "a majority" of micropub clients are updated to include resource?

[dshanske]

I have a few questions about how this would be used:

1. The language so far in [Introduce Resource Indicators #96](https://github.com/indieweb/indieauth/pull/96) covers how an IndieAuth client can include `resource`s in an authorization request, but doesn't mention any mechanism for discovery of resources. Some examples:

Discovery is outside of scope on the PR, but there is also the possibility the endpoint will decide on resources based on the client and/or scope, if it so chooses.

* would a micropub client need to request the micropub endpoint as a `resource`?

Not entirely. The scopes requested would only be understood by the micropub endpoint.

  * how about the micropub media endpoint? note that a micropub client can only learn whether a micropub media endpoint exists by making an authorized `?q=config` request to the micropub endpoint. would the client then need to make a new authorization round trip to get a token with that added `resource`?

One would assume when requesting the media scope, an aware resource supporting endpoint would return the resource parameter if it so chose.

* would a micropub client also need to request `resource`s for the URLs or paths where it wants to create new posts, or update or delete existing posts?

No. Because create scope does that.

* i see a lot of discussion around `resource` for TicketAuth, but I'm not clear on how discovery works here, either. like, how would a feed reader learn which feed URLs it could or should include in a `resource` ask?

That is out of scope for IndieAuth. But Ticket Auth turns that on its head and makes it the responsibility of the publisher to tell the potential consumer. The issue here is the ability to issue a token that can access specific protected resources. There could be a variety of different ways to know how to request such a token that this addition will support. And the way it is written, an IndieAuth endpoint does not have to support resource. In the proposal, it can support scope, resource, or both...but not none. So, 100% backward compatible.

1. What are the compatibility stories for legacy indieauth clients and endpoints? particularly as  either/both `scope` and `resource` are supported. For example, as an author of a micropub endpoint, do i allow tokens with scope-but-not-resource until "a majority" of micropub clients are updated to include `resource`?

Back to, resource is not mandatory.

[martymcguire]

I think a lot of your responses make sense, but for me they are not obvious from the proposed spec changes.

While the spec indicates that scope and resource may be used alone or together, that means this addition would require extra coordination for implementors that want to use IndieAuth.

I think aaronpk summed this up pretty well in the indieweb-dev chat:

the key feature resource indicators adds is the ability for the client to tell the indieauth server where it plans on using the token. if that's not a useful property, then we don't need it

... the AS and RS can already do their own internal logic for limiting capabilities of tokens. this lets the client become part of that negotiation

we are already effectively using "scope" as a resource indicator since we have a list of scopes that are agreed upon between clients and servers

so the question is, is that okay, and can we continue to expand that list to cover the new use cases we are talking about