Introduce Resource Indicators

[dshanske]

Attempts to introduce resource indicators to the spec, as proposed in #82 to address #83(which is specific to ticket auth. Hoping to discuss this at the upcoming Popup.

This adds a parameter, resource, that indicates the target service(s) or resource(s) to which access is being requested. This is a contrast to scope, which talks about access permissions, not what those permissions are accessing. A request could therefore have a resource parameter, a scope parameter, or both. But if neither are requested, no token would be issued.

In the proposed Ticket Auth extension to IndieAuth, for example, a publisher would send a ticket to a potential consumer with the resource parameter, then the potential consumer would redeem the ticket for a resource restricted token, only allowing access to private items under that base URL.

[jamietanna]

Looks good - I guess we don't need to have anything around how i.e. resource=https://api.example.com/ allows access to https://api.example.com/micropub and https://api.example.com/notify, as it's already in RFC8707?

[dshanske]

Needs to add that scope or resource are optional, but scope is not mandatory if resource provided.

[dshanske]

@jamietanna Can you check this again now that I've noted that scope is not required if resource is present and such?

[dshanske]

Refreshed from main.

[jamietanna]

Looks good! Do we want to have a worked example for what a resource would look like for restricting access?

[dshanske]

Looks good! Do we want to have a worked example for what a resource would look like for restricting access?

Can you elaborate? Not sure what that looks like.

[aaronpk]

I do think we should make sure there is a clear path to using this for Ticket Auth before bringing it into the spec. My recollection is that is the primary use case driving this, and that this is a prerequisite for using it in the Ticket Auth extension. Even so, I don't think it's a good idea to bring this in until there is a clear plan for how to use it in an extension. And even then, perhaps it makes more sense to keep it in an extension.

[dshanske]

I agree with the statement this should remain outside the spec until later.

[aaronpk]

We are going to hold off on this until there is a more concrete use case

[dshanske]

Agreed, that's why I removed it from the milestone

[bb010g]

Would OAuth 2.0 Rich Authorization Requests address the non-ticket use cases brought up here? For example, figure 1 from draft 11 shows the common data field locations in use:

{
   "type": "payment_initiation",
   "locations": [
      "https://example.com/payments"
   ],
   "instructedAmount": {
      "currency": "EUR",
      "amount": "123.50"
   },
   "creditorName": "Merchant A",
   "creditorAccount": {
      "iban": "DE02100100109307118603"
   },
   "remittanceInformationUnstructured": "Ref Number Merchant"
}