search

indieweb / indieauth

IndieAuth.net website code and IndieAuth Specification
54 stars 7 forks source link

Path component in client_id considered optional #38

Open cjw6k opened 4 years ago

cjw6k commented 4 years ago

According to https://indieauth.spec.indieweb.org/#client-identifier

Client identifier URLs ... MUST contain a path component

Example clients which provide no path component in client_id:

  1. indiebookclub.biz
  2. indigenous.realize.be (Indigenous for Android, as of 2020-06-16)
  3. omnibear.com
  4. teacup.p3k.io

It is understood that most IndieAuth servers permit clients with valid-in-common-usage client_ids.

Suggestion: modify the spec to match the common usage.

jamietanna commented 4 years ago

Isn't this covered under the following section URL Canonicalization?

As such, if a URL with no path component is ever encountered, it MUST be treated as if it had the path /.

(Originally published at: https://www.jvt.me/mf2/2020/07/hwj5l/)

cjw6k commented 4 years ago

The client_id is specified not encountered, as would be the case were the user to enter the client_id.

^^^ Is my reading. But! I think the MUST in client_id section can become a SHOULD and the rest takes care of itself.

Zegnat commented 4 years ago

Usually I am all for adapting specs after actual real world use, but I am split on this.

The idea with IndieAuth is to enable discovery and do away with client registrations as required in most other OAuth 2.0 implementations. It does this by defining things as URLs. Having an empty path makes it no longer a valid URL.

URLs on http and https are special. According to a note on paths: "A special URL always has a non-empty path."

I think there is a value in saying IndieAuth builds on valid URLs as identifiers, in which case those clients should be fixed. It feels like IndieAuth should not start to document deviations from the URL spec.