Link relations in HTTP Link header conflict with RFC 5988.

[Zegnat]

IndieAuth registers 3 link relations: authorization_endpoint, token_endpoint, and redirect_uri. Additionally it requires both clients and servers to check HTTP Link headers for URLs with these relations.

According to RFC 5988 (as cited by IndieAuth) an _ (underscore) cannot be used by a link relation within the header field. A link’s relation type must match:

  relation-type  = reg-rel-type | ext-rel-type
  reg-rel-type   = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
  ext-rel-type   = URI

RFC 8288 (which replaces RFC 5988, cf. #15) does not solve this for us. There a link’s relation type is defined using a slightly different ABNF but otherwise unchanged:

  relation-type  = reg-rel-type / ext-rel-type
  reg-rel-type   = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
  ext-rel-type   = URI ; Section 3 of [RFC3986]

[aaronpk]

I'm not sure the best path forward on this. We used underscores for authorization_endpoint because that's the same name as the property in OpenID Connect Discovery.

It seems that parsers are not breaking on the underscore, so I would hate to make a breaking change in the spec just to stay conformant with RFC 5988/8288 when in reality the live code seems to not care.

[Zegnat]

[…] I would hate to make a breaking change in the spec just to stay conformant with RFC 5988/8288 when in reality the live code seems to not care.

I agree. So this becomes a question of whether the IndieAuth specification needs to call notice to this deviation from RFC 8288. Alternatively the issue gets ignored completely, or it is filed somewhere else.

---

As far as link relations in HTML are concerned, the WHATWG accepts any “JavaScript string” (basically: any valid UTF string) that does not contain ASCII whitespace. As long as the type is “registered in the microformats wiki”. Underscores are definitely fine there, and have some prior art.

[aaronpk]

Perhaps the way forward on this is to switch to an IndieAuth Server Metadata URL #43 and use a name that isn't disallowed for that endpoint.

[dshanske]

@Zegnat Do you consider this resolved as we used a - in the replacement for these, save redirect_uri ?

[Zegnat]

@dshanske Feels like this is pending closing by #133. As that would potentially introduce a different recommended way to detect redirect_uri (as redirect_urls) in the Client ID Document.