- Edited
Many services allow verification of a personal site by one of the following mechanisms:
- adding a
meta
tag to thehead
of the page - adding a specific .txt file at a well-known URL
(eg Keybase supports this)
I know the objections to parsing generic HTML pages – boiling down to (a) fragile parsing and (b) what about user generated content. But I don't think either of those issue apply here.
Specifically, I am proposing we implement one or both of the following mechanisms:
<link rel="pgpkey" ...>
in the HTMLhead
.
This proves ownership of a specific page at a specific URL. If it's at the root of the domain, that could be considered to prove ownership of the whole site.
I don't think the objections to HTML parsing apply because (a) it's a well-defined link rel value in the head, not an arbitrary DOM path which would be subject to fragile parsing, and (b) if it's in the head, the potential for user-generated content (eg comments) messing with it isn't an issue.
Therel="pgpkey"
value is already used for RelMeAuth, amongst others.
The link href points to an ASCII-armoured key, so the same implementation would solve Git forges and Facebook and Keybase.
Alternatively we could use a custommeta
tag containing the fingerprint. I prefer thelink
version though since it's already used for other things.A text file at a well-known URL.
Keybase uses this method. Unfortunately they use a file in the root directory of the site, instead of in.well-known
, but it works the same way. The file could contain the fingerprint or maybe even the ASCII-armoured key, or it could just have the fingerprint as the filename.
Either of the above methods would mean we could support Neocities, for instance, without needing a special implementation just for that site based on their API.