In case it's not clear, all of these are "filenames" contained within the .well-known "directory". The Wikipedia link below [1] has more examples of Well-Known URIs being used already.
First, whoever decided on .well-known starting with a . (making it normally a hidden directory) was a complete moron. I don't care what the pedantic reasoning was, it was idiotic. It's publicly accessible, yet hidden from admins unless they're looking for it?? It's like a security leak waiting to happen.
Secondly, I don't think I've ever seen a more chaotic list of naming conventions in my life:
* Non-descriptive names or acronyms: coap, core, posh, ni, dots.
(You have to admire that last one in terms of just screwing with admins.)
* Multiple names with dashes: stun-key, reload-config, apple-app-site-association
* Multiple names without: nodeinfo, openpgpkey
* Multiple names with dots: com.apple.remotemanagement
(I love how Apple can't decide).
* Names with extensions: security.txt, ai-plugin.json, host-meta.json
* Names that have apparently optional extensions: host-meta
* Subdirectories: autoconfig/mail
It's complete anarchy. Does the W3C actually want anyone to maintain this chaos? It must be the least well thought out "specification" that's ever been inflicted on the world.
IANA (not w3c) just maintains a directory of who uses them to avoid collisions.
As should be obvious from the collection, there’s nobody in charge here. You can just ask for whatever prefix you want. I guess in that way, I agree with you: it is nearly anarchy.
I personally think that’s fine. Why does it matter if the names aren’t consistent? The different protocols using well-known don’t have to talk to each other. Any individual program is likely to just care about one for whatever protocol it’s speaking. All that matters is they don’t overlap.
Imagine this is a code library and I think it’ll become clear that while only uniqueness may be strictly necessary, inconsistent, undescriptive naming is harmful to API consumers, and to a lesser extent harmful to the implementers.
These are registrations, not documentation of independent usage, so yes, there’s somebody in charge, the IETF. They can enforce good naming, and do: https://datatracker.ietf.org/doc/html/rfc8615#section-3. They just apparently have either granted or grandfathered in many exceptions.
I hadn't seen this before... At least it calls out how dangerous the .well-known directory could be. So that's good. /s
4.4. Hidden Capabilities
Applications using well-known locations should consider that some server administrators might be unaware of their existence (especially on operating systems that hide directories whose names begin with "."). This means that if an attacker has write access to the .well-known directory, they would be able to control its contents, possibly without the administrator realising it.
> Well-known URIs can be registered by third parties (including the expert(s)), if the expert(s) determine that an unregistered well-known URI is widely deployed and not likely to be registered in a timely manner otherwise. Such registrations still are subject to the requirements defined, including the need to reference a specification.
So if some non-IETF protocol starts using a .well-known path, it can get added to the IANA registry even if the protocol authors themselves don’t register it.
At least no one ever tried to register names with unusual punctuations [1]. `autoconfig/mail` is not registered FYI.
[1] RFC 8615 requires that all names should conform to RFC 3986 `segment-nz` production, which is virtually any plausible character minus slashes (the exact regexp is `([A-Za-z0-9\-._~!$&'()*+,;=:@]|%[0-9A-Fa-f]{2})+` if you wonder).
13 comments
[ 0.23 ms ] story [ 45.0 ms ] threadFirst, whoever decided on .well-known starting with a . (making it normally a hidden directory) was a complete moron. I don't care what the pedantic reasoning was, it was idiotic. It's publicly accessible, yet hidden from admins unless they're looking for it?? It's like a security leak waiting to happen.
Secondly, I don't think I've ever seen a more chaotic list of naming conventions in my life:
* Non-descriptive names or acronyms: coap, core, posh, ni, dots.
(You have to admire that last one in terms of just screwing with admins.)
* Multiple names with dashes: stun-key, reload-config, apple-app-site-association
* Multiple names without: nodeinfo, openpgpkey
* Multiple names with dots: com.apple.remotemanagement
(I love how Apple can't decide).
* Names with extensions: security.txt, ai-plugin.json, host-meta.json
* Names that have apparently optional extensions: host-meta
* Subdirectories: autoconfig/mail
It's complete anarchy. Does the W3C actually want anyone to maintain this chaos? It must be the least well thought out "specification" that's ever been inflicted on the world.
1. https://en.m.wikipedia.org/wiki/Well-known_URI
I wish people wouldn't bring it up every time the idea of standardization is mentioned.
As should be obvious from the collection, there’s nobody in charge here. You can just ask for whatever prefix you want. I guess in that way, I agree with you: it is nearly anarchy.
I personally think that’s fine. Why does it matter if the names aren’t consistent? The different protocols using well-known don’t have to talk to each other. Any individual program is likely to just care about one for whatever protocol it’s speaking. All that matters is they don’t overlap.
These are registrations, not documentation of independent usage, so yes, there’s somebody in charge, the IETF. They can enforce good naming, and do: https://datatracker.ietf.org/doc/html/rfc8615#section-3. They just apparently have either granted or grandfathered in many exceptions.
4.4. Hidden Capabilities
Applications using well-known locations should consider that some server administrators might be unaware of their existence (especially on operating systems that hide directories whose names begin with "."). This means that if an attacker has write access to the .well-known directory, they would be able to control its contents, possibly without the administrator realising it.
https://datatracker.ietf.org/doc/html/rfc8615#section-3.1
> Well-known URIs can be registered by third parties (including the expert(s)), if the expert(s) determine that an unregistered well-known URI is widely deployed and not likely to be registered in a timely manner otherwise. Such registrations still are subject to the requirements defined, including the need to reference a specification.
So if some non-IETF protocol starts using a .well-known path, it can get added to the IANA registry even if the protocol authors themselves don’t register it.
[1] RFC 8615 requires that all names should conform to RFC 3986 `segment-nz` production, which is virtually any plausible character minus slashes (the exact regexp is `([A-Za-z0-9\-._~!$&'()*+,;=:@]|%[0-9A-Fa-f]{2})+` if you wonder).