Drop specification for communication between authorization and token endpoints.

[Zegnat]

There has been some confusion surrounding when and how to issue requests for access token verification from the token endpoint. Sections 6.3.2. and 6.3.3. One such occasion was today in chat. Here a Micropub client was first doing authentication verification (and expecting an answer similar to what a token endpoint would expect) and then doing a token request with the same access code. This worked with some implementation, but not all.

In fact, on quick read the IndieAuth specification does not make it clear at all that implementing sections 6.3.2 and 6.3.3. is completely optional. These steps are only necessary when you expect a token endpoint to talk to the authorization endpoint over HTTP. At least one private implementation (aaronpk’s) never returns scope values on verification requests because it does not support these sections.

There are multiple implementations where the authorization and token endpoints exist within the same infrastructure. Like the WordPress plugin. These implementations never need to implement HTTP access code verification between the two endpoints and the sections are completely optional.

Going forward: should we drop these extra steps from the base IndieAuth specification completely?

The concept could instead be documented as an extension limited to implementers who need the modularity.

[martymcguire]

+1 to documenting as an extension and including a reference in the main spec!

[aaronpk]

Thanks for capturing this @Zegnat!

To clarify, the proposal would be to remove sections 6.3.2 which talks about token-endpoint-to-authorization-endpoint communication and instead create a new extension spec that provides that functionality.

[fluffy-critter]

This has been a long standing point of confusion to me as well. I approve of any change that makes the roles of the endpoints and the expectations of communication between them more clear.

On the other hand, making it an optional extension might further muddy the waters in the future when it comes to implementing things that make use of third-party token grants, although I don't know of any things that actually do that right now. If something like that comes up and gets popular, I guess the optional extension becomes more popular too. 😄

[aaronpk]

This was discussed at the IndieAuth Popup Session, and the outcome of the discussion was:

• Similar to #19, this feature is underused or misused, and has caused more confusion than it has helped
• This could be done with an extension, which would also need to define the stuff dropped in #19 if it wanted
• Nobody really seemed to care about creating an extension for this