Should the token endpoint be shared with normal IndieAuth?

[sebsel]

At IWC Åmål, we discussed some questions I had after trying to implement a token endpoint for ‘normal’ IndieAuth and AutoAuth. One of my questions was about the two calls that are made by the token endpoint to the auth endpoint, which differ greatly for both the flows.

For the normal flow, one would send code, client_id and redirect_uri to the auth endpoint associated with the owner of the token endpoint. For AutoAuth, one would send code, root_uri, realm, scope and callback_url to the auth endpoint associated with the user that tries to access the resource (eg. feed). These two sets only have code in common.

This does not have to be a problem, but I asked why it was. The point is that the auth endpoints belong to different parties, thus having different trust relationships between the token endpoint and the auth endpoints.

It also made us question whether or not the token endpoint of AutoAuth is or should be the same as the token endpoint for regular IndieAuth, as they play different roles. @Zegnat pointed out that a big part of there role is one-on-one the same, and that it was nice to have one database of all tokens. I on the other hand pointed out that I would like to separate the database with tokens that point to me vs tokens that point to anyone who tried logging into my site. @sknebel wanted to think more about the matter, hence this issue.

Could it be that this token endpoint is a different endpoint (which is advertised on the resources they apply to, rather than the homepage of the user) and should it have a different rel-value then too? Or should there really be one endpoint?

[sknebel]

Just to clarify:

Could it be that this token endpoint is a different endpoint (which is advertised on the resources they apply to, rather than the homepage of the user)

The token endpoint for AutoAuth is discovered from the resource! But it is using the same rel-value, so if the resource is a profile page supporting IndieAuth, the endpoint has to support both.

I currently run completely different code for IndieAuth from my homepage and for AutoAuth (so I can currently not provide AutoAuth for my front page), which might suggest having a different rel is fine - next question then is "then what's that one called?"

[sknebel]

My current thinking would be to do an experimental extra name, and suggest applications look for that first, and fall back to token_endpoint if it is not present.

Still don't have a good idea about a name. I'd like to avoid putting "autoauth" in the name. remote_token_endpoint seems all kinds of wrong too, but is the best I can come up with.

[mblaney]

I thought there was a move away from experimental names because we end up getting stuck with them, same as -x prefixes etc. I like the idea of keeping the endpoint the same unless there's a good reason not to. The discussion above is more about where you store the token rather than the endpoint, and that is an implementation detail? If you need to tell the two types of tokens apart you can create separate tables or add an extra field etc. but I'm still not sure you do need to tell them apart?

[sknebel]

The motivation for an extra endpoint isn't so much about storage, but about being able to not change your existing token endpoint (e.g. because you've setup your micropub etc using an external one and don't want to touch that) while implementing AutoAuth.

[mblaney]

ok fair enough, I would feel better commenting after I've put more work into implementing both sides of this. I still think it's less work overall to ask people writing token endpoints to do the extra check for AutoAuth rather than making everyone else parse out another rel value. Even better if we can make existing token endpoints continue to work as they are, and those that are capable of AutoAuth just need to check for extra parameters?