Closed dshanske closed 7 months ago
In my opinion, the proposal to add the issuer parameter, which would indicate the authorization server that was issuing the ticket and would therefore issue the token makes sense. However, if you are discovering the indieauth metadata endpoint from the issuer parameter...I just checked and my issuer URL does not have the header on it. Probably should, considering.
I think it is better as a parameter than client_id and is consistent with the authorization_code flow we've put into IndieAuth. Are there any other steps in this flow we'd need to add though?
I’ve implemented this: my ticket_endpoint
will accept a (currently optional) iss
parameter. If that’s included, the endpoint will check that the issuer URL advertises indieauth-metadata
endpoint and is valid as described in the spec.
I think I like this solution to the privacy concern. It also avoids the overhead of advertising endpoints on multiple resource URLs. So I lean towards requiring the iss
when sending a ticket. However, I’m not sure how many implementations might send an issuer URL that does not advertise the metadata endpoint.
(Originally published at: https://gregorlove.com/2023/11/ive-implemented-this/)
Proposing this text.
The ticket endpoint makes a GET or HEAD request to discover the metadata endpoint of the issuer property, to discover the token endpoint. The issuer property MUST allow for discovery of the metadata endpoint. If no issuer property is provided, the ticket endpoint SHOULD try to discover the metadata endpoint at the resource. If no metadata endpoint discovery is possible, the ticket endpoint MAY fall back onto the older token endpoint discovery process.
Okay, taking one of @gRegorLove 's points into consideration.
Proposing this text.
The ticket endpoint makes a GET or HEAD request to discover the token endpoint,as described in [Discovery by Clients](https://indieauth.spec.indieweb.org/#discovery-by-clients), with the difference that instead of discovery at the user provided URL, discovery will use an issuer property if provided. Only if no issuer property is provided will it try discovery at the resource URL
So, mapping this out with the issuer parameter.
Does using issuer as a parameter and, in this scenario, using that to determine where the token endpoint is have any other implications? Security or otherwise?
We've established the reason is that the resource advertising a metadata endpoint could indicate there is something there to access, which may not always be the case.
If the question is why not just send the token endpoint URL to tell the ticket endpoint where to redeem, I think confirming the supported grant_type is a good step, which puts us back with needing the metadata endpoint. But, why not send that, rather than the issuer identifier?
My first question is: when the RO sends a ticket, is iss
required? If it's optional, that feels like it makes the process more complicated with if/else conditions for the subject
. I'm leaning towards requiring it and my in-progress implementation sends it. I'm interested to hear others' thoughts.
Re: the question of sending the token_endpoint
directly along with the ticket, I can't immediately think of a vulnerability, but it feels safer if the receiving ticket_endpoint
discovers it from iss
, which would prevent spoofing the token_endpoint
.
My first question is: when the RO sends a ticket, is
iss
required? If it's optional, that feels like it makes the process more complicated with if/else conditions for thesubject
. I'm leaning towards requiring it and my in-progress implementation sends it. I'm interested to hear others' thoughts.Re: the question of sending the
token_endpoint
directly along with the ticket, I can't immediately think of a vulnerability, but it feels safer if the receivingticket_endpoint
discovers it fromiss
, which would prevent spoofing thetoken_endpoint
.
I'd prefer it required it myself
Based on the suggestion of @jamietanna and concurrence from @gRegorLove, @jalcine, and myself have added this into the proposed extension.
Currently the only thing it is sent that it can act on is the resource value. If that is also supposed to function as sort of a root URL of resources it gives access to, is it correct to assume the token endpoint can be discovered at that exact URL? (See first open Q.)