About

Weather Vane is a tool that can be used to verify identities and links contained in did-method-plc and did-method-web documents. It performs bi-directional verification to ensure that claims are accurate and trustworthy.

Example: did:plc:cbkjy5n7bk3ax2wplmtjofq2

Help

Here are some of the frequently asked questions about Weather Vane.

How can I use it?

Using the form at the top of the page, enter the ATProtocol handle or DID that you would like to verify, and submit the form.

All of the identities associated with the account will be listed along with their verification status.

How does it work?

In Bluesky, and as a part of the larger ATProtocol ecosystem, you have a DID that is used to help servers understand where to send requests to. The did-core technical specification for how DIDs work includes the ability to link identities with the alsoKnownAs attribute.

Weather Vane reads this information and performs bi-directional verification of the linked identities described in DID documents.

What is bi-directional verification?

Bi-directional verification is the process of verifying that a DID document contains a reference to an identity and that the identity contains a reference to the DID document.

For example, if a DID document contains a reference to a website, the HTML served when you visit the page must contain a reference to the DID document in the form of an element like <link rel="did" href="did:plc:decafbad">.

Why is this important? Bi-directional verification shows mutual consent and control.

For example, let's say that you are @johnny-awesome-handle and blog at https://the-greatest.of-all-time/.

By including the URL of your blog in your DID document, you are proving that you are the account holder of the handle @johnny-awesome-handle. By creating a DNS record on the domain that points back to your DID, you are proving that you have control over the domain.

Those mutual controls represent bi-directional verification because you need access to and control over both the account and domain to configure them to point to each other. If someone didn't have access and control over the domain or website, they wouldn't be able to create the necessary records to point back to their DID.

How can I verify it manually?

Verifying the identities referenced by a DID document can be time consuming, but it is possible to do so manually.

1. First, resolve the identifier to the DID document.

   • For did-method-plc DIDs, you can look them up on plc.directory.
   • For did-method-web DIDs, you'll need to make an HTTP GET request to the expanded DID json document per the spec.

2. Enumerate the alsoKnownAs array in the DID document and verify each

   • did-method-web identities can be resolved as per their spec.
   • did-method-plc identities can be resolved as per their spec.
   • DNS identities can be resolved by a TXT query to the value
   • GitHub identities can be resolved through an API call to the user social identities API endpoint and further resolution of the "bluesky" URL.
   • Websites can be verified by making a HTTP GET request to the URL and verifying the presense of a link element with a rel attribute of "did" and a href attribute that matches the DID.

Why use this instead of a labeler

Label services can be appealing because of the instant gratification they provide, but they are not a good solution for verifying identities and cause active harm.

1. They centralized identity and authority, which is antithentical to ATProtocol.
2. They remove your autonomy and control, by forcing you to rely on a third party that you have no long-term control.

How can I add my identities to my account?

Adding identities to your account is a multi-step process that involves updating your DID document and verifying the identities.

Visit /guide for instructions.