Open dshanske opened 3 years ago
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/)
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
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.
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.
This suggestion begs the question, should you be able to query this somewhere...#43 ?
I have a few questions about how this would be used:
The language so far in #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:
resource
??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
?resource
s for the URLs or paths where it wants to create new posts, or update or delete existing posts?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?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
?
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.
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
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.