IndieAuth 2 2021 was an IndieWebCamp Pop-ups 2021 session and the 2nd IndieAuth session of 2021.
At the end of the last IndieAuth protocol session, there was a discussion of following up in a few weeks to finish what we could not. This popup IndieWebCamp session will continue the discussion to iterate and evolve the IndieAuth protocol.
- facilitators: Aaron Parecki
- Participants: David Shanske, David Somers [omz13], capjamesg, Jamie Tanna, Martijn van der Ven
- Date: 2021-10-16
- Time: 07:30 Pacific
- event: https://events.indieweb.org/2021/10/indieauth-2-popup-session-5y88zAw4LtO9
- hashtag: #indieauth2
- Video: ▶️01:59:24s
- Etherpad: https://etherpad.indieweb.org/2021-10-indieauth-popup
Archived from https://etherpad.indieweb.org/2021-10-indieauth-popup
- Make IndieAuth token introspection endpoint credentialed, so it is clear that this should only be used by Resource Servers. While there was a consensus on adopting the token introspection endpoint request and response, we did not conclude on what type of authentication. https://github.com/indieweb/indieauth/issues/99
- Authentication is likely to be required, but in practice, requires further investigation (see below)
- Aaron Parecki would like this to be some sort of dynamic client registration / "enrollment" that happens automagically when i.e. setting up a relationship with Aperture
- Discussion as to whether i.e. Aperture / other shared platforms could lead to needing some out-of-band authentication sharing - follow-up investigation required
- Jamie Tanna notes that, while integrating his IndieAuth server with OAuth2 clients, he found that the token_endpoint (not the token introspect endpoint, as mentioned on the call) may require `client_id` to be retrieved from `Authorization: Basic ...`, depending on how they work
- Jamie Tanna has implemented this, and integrated this using the Spring Security and rack-oauth2 OAuth2 clients, and allows for using empty authentication (which could then be HTTP Basic Auth)
- Consensus for now: Add to PR on introspection it is required, but not specify how at this time, allowing implementers to decide.
- Introduce OAuth Server Metadata https://github.com/indieweb/indieauth/issues/43
- Jamie Tanna has a metadata endpoint now, getting it working was pretty straightforward
- David Somers has a metadata discovery facility: see https://toolbox.imoxia.com/#authmetadisco (now supports discovery using rel=indieauth_metadata)
- Rel=indieauth-metadata as opposed to rel=indieauth to indicate it is the metadata endpoint over being confused for the issuer URL. Opportunity to use - over _ as _ not allowed in http headers.
- May address #98 in that we could more easily add endpoints.
- Recommend placing it as .well-known for compat, but not require?
- Note about fallback to old endpoints for compat
- Consider adopting the iss parameter https://github.com/indieweb/indieauth/issues/101
- Dependent on the iss parameter being defined in the server metadata document. So, no fallback if there is a metadata document.
- iss value should be the home page of the indieauth server, and is expliclty not the authorization endpoint
- Discuss whether IndieAuth adopt resource indicators(https://github.com/indieweb/indieauth/issues/82) as a notation, and note any specific considerations for IndieAuth. Even though Ticket Auth prompted this, this is not specifically a Ticket Auth issue. Proposed PR https://github.com/indieweb/indieauth/pull/96
- Jamie Tanna adds the `aud` of `https://www-api.jvt.me/` into all tokens, and currently does not enforce it anywhere. The enforcement would be added in the future, restricting at a resource server level whether the access token can be utilised
- Discussion is also around whether we use Resource Indicators for Ticket Auth
- Sample private post doing www-authenticate: https://toolbox.imoxia.com/private/codecow with a realm indicator
- Scopes may not be required if resources are provided, and this could be specified in spec.
- Whether an access token is issued changes from only whether scopes are requested to whether scopes or resources are requested
- Making the various token endpoint overrides consistent https://github.com/indieweb/indieauth/issues/98
- Rewrite Introspection PR to support metadata to no longer be part of token endpoint as proposal.
- Consider rewriting revokation to be defined as an endpoint with server metadata.
- Clarifying what names are returned in user profiles https://github.com/indieweb/indieauth/issues/93
- Define name in the spec and its application.
- It feels like the most straightforward solution would be to keep the existing "name" param and define it more specifically in the spec
- Clarify whether profile information is returned when a refresh token is used
- Consider adopting a userinfo endpoint, possibly after OAuth server metadata
- What clients can we test with?
- Jamie Tanna has used https://github.com/FusionAuth/fusionauth-jwt/ to provide OAuth Server Discovery by $issuer or by $issuer/.well-known/...
- Jamie Tanna seems to have found support in Spring Security https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/registration/ClientRegistrations.html#fromIssuerLocation(java.lang.String)
- Client Information Discovery improvements.
- Should this solely rely on Microformats? https://github.com/indieweb/indieauth/issues/23
- Should we adopt a manifest file and what should be displayed if no app info discovered? https://github.com/indieweb/indieauth/issues/64. #23 suggests other fields that might be relevant, such as the icon and name from the page.