-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify relationship between authorization_endpoint and token_endpoint in protocol flow diagram #77
Comments
I would just want to have a good thing about how to do it without making it look like it is a must for the two services to be one and the same thing. It is actually completely fine for the two endpoints to communicate with eachother using the old IndieAuth specced way of inter-communications. It is just that the August 2020 update declared it underused, which is written up as out of scope in the spec:
I do not know if this out of scope is best attributed by having a special arrow between the two lanes labelled as such, or by adding a box around them, or what. I just do not want the diagram to give people the idea it must be boxed in as one service. (Boxed in, get it? I’ll see myself out.) |
Perhaps a dashed border around the two endpoints, with a footnote noting that they can potentially be located on different services, but that the diagram assumes that they’re part of the same service for simplicity? Did the auth <-> token endpoint communication protocol get written up as an extension anywhere? If so, the footnote could link to it. |
I don't think anybody cared enough to write it up as an extension yet |
I think we only really established two implementations? IndieAuth.com which is planned to be deprecated, and my own MinToken which I will also be replacing for my use. But it should be easy enough to write it up as an extension by just copying the old spec, if anyone were to show an interest. |
I've added a box around the authorization server parts, I agree it makes it a bit clearer. Done in 1f4f4ad |
Currently, the protocol flow diagram shows the auth and token endpoints as being distinct entities to the same degree as the user’s browser or homepage. However, the spec assumes that the two endpoints are closely linked i.e. live in the same web app, have access to the same storage etc.
To make their relationship clearer, I propose the following:
If more detailed architecture and/or application diagrams are made, I propose similar measures are taken there to clarify the relationship between the two endpoints (#26, #27)
The text was updated successfully, but these errors were encountered: