Where does the ticket endpoint go looking for the token endpoint?

[dshanske]

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.)

• @Zegnat ended up setting the resource as their root domain, which made it impossible to go get a token with the token endpoint only discoverable from the /martijn/ path. This was because of the assumption that resource was like realm in that it could be anything, but that stopped the ticket endpoint @dshanske was writing from ever redeeming. Short discussion in chat.. @jamietanna agrees with @Zegnat 's point about it being in the initial POST to the ticket endpoint, and matching the identity URL of the user who is providing access
• @jamietanna wondered if that was something that can be fixed by providing a specific iss/issuer value along with the resource in the POST to the ticket endpoint and added this to their proof of concept. Namely, should the iss matching the issuer of the token (i.e. the IndieAuth server's URL)
• It was pointed out that by putting the token endpoint header on a resource URL, you may be indicating there is something there. For example, you choose to have your private pages return 404. Then how does the ticket endpoint discover the token endpoint?

[dshanske]

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?

[gRegorLove]

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/)

[dshanske]

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.

[dshanske]

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

[dshanske]

So, mapping this out with the issuer parameter.

• Resource Owner sends ticket. Ticket includes ticket code, resource, subject, and issuer.
• This is effectively saying, if you(subject), want to access resource, you need to redeem this ticket issued by issuer.
• So, the ticket endpoint, acting as a client, will poll the issue to find the metadata endpoint, and then discover the token endpoint and verify in the metadata that the ticket grant type is supported.
• Redeem the ticket and receive a token.

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?

[gRegorLove]

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.

[dshanske]

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.

I'd prefer it required it myself

[dshanske]

Based on the suggestion of @jamietanna and concurrence from @gRegorLove, @jalcine, and myself have added this into the proposed extension.