Open dshanske opened 2 years ago
Needs to add that scope or resource are optional, but scope is not mandatory if resource provided.
@jamietanna Can you check this again now that I've noted that scope is not required if resource is present and such?
Refreshed from main.
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.
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.
I agree with the statement this should remain outside the spec until later.
Agreed, that's why I removed it from the milestone
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"
}
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.