Many services allow verification of a personal site by one of the following mechanisms:

  • adding a meta tag to the head 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 HTML head.
    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.
    The rel="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 custom meta tag containing the fingerprint. I prefer the link 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.

    caesar 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.

    On further investigation, although example.com/keybase.txt is the default, example.com/.well-known/keybase.txt is also supported and is registered with IANA.
    Keys.pub also uses a well-known URL (example.com/.well-known/keyspub.txt), though it is not registered with IANA.

    I mention the above examples only to show that this is generally considered a secure way to prove ownership of a site, including by security professionals.

      5 months later

      Hey there! Sorry for the delay, but working on this right now!

      caesar 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.

      Makes perfect sense. I am trying out a simple HTML parser and it makes it simple to obtain just the meta tags inside of the head, so a nice solution.

      caesar <link rel="pgpkey" ...> in the HTML head

      I am fine with this but in time, I would like to get additional tags imagined and supported for non-PGP keys, which will be coming to Keyoxide within the coming year.

      caesar A text file at a well-known URL.

      Can do that, would be great to have as well.

              In the Matrix chat, the following was proposed:

              <meta name="ariadne-proof" content="FINGERPRINT" data-url="LINK-TO-KEY" data-signature="SIGNATURE">

              This would allow direct identity verification without ever needing to go through a Keyoxide profile.

              Based on the following documentation and links:

                yarmo Sorry for the delay, but working on this right now!

                Great!!

                yarmo In the Matrix chat, the following was proposed:

                <meta name="ariadne-proof" content="FINGERPRINT" data-url="LINK-TO-KEY" data-signature="SIGNATURE">

                I can't see the Matrix conversation because I was "kicked for being idle", and the room settings don't allow me to see conversations that happened while I wasn't in the room. Do you think you could summarise here the reasons behind this proposal?

                My initial thoughts:

                • Ignoring the other attributes (partly because I'm not sure yet what they're for 🙂):<meta ... data-url="..." /> seems like a poor substitute for <link ... href="" />. A link tag has the specific well-defined purpose of linking to related resources, whereas data-* is by definition unstructured / application-specific data.
                  Of course, if you already want the meta tag for holding those other attributes, that's a different story, but I think it's worth considering the semantics the link tag has to offer.

                • <link rel="pgpkey" href="..." /> is already in use elsewhere, so even if you want to add the above meta tag as an option, it would be nice to support link rel="pgpkey" too. It may have a more limited use case, but I think it's important to support existing metadata when it exists.

                      Further to my first point, I should note that the HTML5 spec explicitly states the following:

                      a new metadata name should not be created in any of the following cases:

                      • If either the name is a URL, or the value of its accompanying content attribute is a URL; in those cases, registering it as an extension to the predefined set of link types is encouraged (rather than creating a new metadata name).

                      Whilst in the case of your proposal the content attribute isn't strictly a URL, I would think that adding a data-url property to a meta tag is at least similar in concept, so it's something worth thinking about.

                        caesar the room settings don't allow me to see conversations that happened while I wasn't in the room

                        Oh no, that's not good! I just set the Who can read history? to Anyone, hopefully this will prevent issues like this in the future.

                        caesar Do you think you could summarise here the reasons behind this proposal?

                        Truth be told, there was only one message not by me on the topic, so allow me to transcribe the entire discussion here 🙂

                        erAck> I'd go for 2 and add a url="..." pointing to the full delivering URL and a signature="..." attribute, signing the url content. Thus it can be verified that the HTML snippet was inserted by the key owner in that specific page even without the key proofs.

                        Option 2 was the novel meta tag, option 1 the pgpkey link tag and 3 the well known file. I personally suggested supporting at least two, preferably all three.

                        Having said that, I'm still not in favor of these extra data attributes, however we may choose to present them.

                        All Ariadne/Keyoxide proofs are simply a piece of text in biographies, posts, wherever we can put it. I see no reason to change this for websites.

                        So, my vote still goes to <meta name="ariadne-proof" content="... />, nothing more, nothing less. This IMHO should be implemented together with <link rel="pgpkey" href="..." />, giving people the choice of either or both.

                        caesar Whilst in the case of your proposal the content attribute isn't strictly a URL, I would think that adding a data-url property to a meta tag is at least similar in concept, so it's something worth thinking about.

                        Agreed so I hope you'll agree that my proposal sans additional attributes is valid.

                              I wrote in the Matrix/IRC chat:

                              I'm still not convinced, I don't like how 1- this breaks convention and 2- it's partially redundant with the link rel="pgpkey" tag. What if we separated the tags?

                              <link rel="pgpkey" href="…">
<meta name="ariadne-proof" content="…">
<meta name="ariadne-signature" content="…">

                              This way, people can just use what they want: some already link to their pgpkey. Some might want to add a proof. And some might even want to add that signature of that pgpkey URL. And there won't be redundancy.