Closed aaronpk closed 2 years ago
If the new version of IndieAuth is not backwards compatible, I would vote for a major change of the version number and call it 2.0 (https://semver.org/).
Is this expected to be similar to OpenID Connect Discovery?
What sort of properties are we thinking would be provided?
I would guess:
authorization_endpoint
grant_types_supported
response_types_supported
scopes_supported
token_endpoint
But is there anything specific we'd want for IndieAuth? Maybe something like whether we support #40?
I don't know enough yet to comment on whether this is needed, but if it is, what about simply rel="indieauth"
, without the "_metadata"? That seems more consistent with "micropub", "microsub", and "webmention".
Technically once you add all the OAuth 2.0 extensions on top, OAuth 2.0 isn't even backwards compatible with itself. But in any case, the name isn't super relevant to this discussion.
The extension point from OAuth is RFC8414. The two main ones needed are authorization_endpoint
and token_endpoint
, I could see scopes_supported
potentially being useful too. In general I'd want to leave out as much as possible unless there's a clear reason to add it.
rel="indieauth"
could work, I guess I suggested indieauth_metadata
first because this URL isn't the indieauth server itself, it's a document describing the server. But in any case it's more important to decide whether this is even a good idea than what it's called right now.
Removing this from the GitHub milestone for now while we focus on the current open issues we discussed at the popup.
We should revisit this once we have a backwards-incompatible change we want to make to IndieAuth such as #40
My IndieAuth server now supports this at https://indieauth.jvt.me/.well-known/oauth-authorization-server
:
{
"authorization_endpoint": "https://indieauth.jvt.me/authorize",
"code_challenge_methods_supported": [
"S256"
],
"grant_types_supported": [
"refresh_token",
"authorization_code"
],
"introspection_endpoint": "https://indieauth.jvt.me/token_info",
"issuer": "https://indieauth.jvt.me",
"response_modes_supported": [
"query"
],
"response_types_supported": [
"code"
],
"scopes_supported": [
"read",
"profile",
"update",
"mute",
"media",
"follow",
"delete",
"notify",
"channels",
"draft",
"undelete",
"create",
"block"
],
"token_endpoint": "https://indieauth.jvt.me/token"
}
My profile URL shares:
rel=indieauth "https://indieauth.jvt.me"
rel=indieauth-metadata "https://indieauth.jvt.me/.well-known/oauth-authorization-server"
Note that in #17 we shouldn't use underscores in HTTP headers.
rel=indieauth-metadata
@jamietanna Can you clarify what "response_modes_supported" means in your example? I am thinking of implementing this but was not sure what other values someone could state.
@capjamesg sorry for the late reply, the response_modes_supported
means where the Authoritzation Server will put the code
parameter into the redirect as part of the Authorization Code Grant.
For IndieAuth, it's always query
as it's in the querystring.
Just thought I'd add the metadata for it
Thank you for the clarification @jamietanna.
Closing, as this is now adopted by #102.
Currently IndieAuth clients discover two pieces of information from the user's profile page, the authorization endpoint and token endpoint. As we continue to expand IndieAuth into new use cases (such as automated indieauth between two machines acting on behalf of users), we may need to include additional information to clients.
If IndieAuth 1.1 is not backwards compatible with IndieAuth, (such as if PAR is a requirement), clients will need to know which version is supported in order to know how to behave, and that means either adding another link tag or changing the names of the rel values.
There is an OAuth extension which talks about how to communicate information about an OAuth server to clients by publishing a JSON document at the metadata URL for the server.
We could instead have the IndieAuth client look for just one value in the HTML, the metadata endpoint, and have the client fetch everything else from there. While this does add an HTTP request in the initial setup compared to the current state, it may end up being preferable longer term. (PAR ends up adding a request in the setup too anyway.)
A straw proposal for how this could work is:
<link rel="indieauth_metadata" href="https://indieauth.example.com/metadata.json">
(the filename does not need to be standardized since it's discoverable from this link)authorization_endpoint
andtoken_endpoint