did:web Reference

What did:web is

did:web is the simplest DID method in the W3C DID Core spec: the DID document lives at a well-known HTTPS URL, and resolution is just an HTTP GET. BoxOwl publishes a DID document for the domain itself and one for every user.

The DID model gives every BoxOwl identity two properties that a username alone can't:

• Verifiable — a public key tied to the identity is published in the DID document, so an external party can verify signatures (e.g. on a shared profile snapshot) without trusting BoxOwl.
• Portable — your DID resolves the same way regardless of which client is asking. The handle-form is friendly; the UID-form is permanent.

Three DIDs to know

UID lookups accept both the dashed display form (e.g. ABC-DEF-GHI) and the undashed form (ABCDEFGHI) — the controller normalizes before resolving.

Domain DID document

GET https://boxowl.me/.well-known/did.json

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:web:boxowl.me",
  "verificationMethod": [
    {
      "id": "did:web:boxowl.me#key1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:web:boxowl.me",
      "publicKeyMultibase": "z6Mk..."
    }
  ],
  "authentication": ["did:web:boxowl.me#key1"],
  "assertionMethod": ["did:web:boxowl.me#key1"]
}

The domain key signs platform-level attestations and is the trust root for BoxOwl-issued claims.

User DID document

GET https://boxowl.me/did/user/{handle} or https://boxowl.me/did/uid/{uid}

Each user has a unique Ed25519 keypair (the private half is server-encrypted with the platform KEK; the public half is published in the DID document). The user's DID document follows the same shape as the domain document and adds service entries pointing at their public profile and verifiable presentation endpoints.

A 404 means either the handle/UID doesn't exist or the user's public profile is disabled — the DID document is intentionally unavailable in that case.

Authentication & assertion

Both verification arrays reference the same key by default. The key is used for:

• Authentication — proving control of the DID in W3C Verifiable Credential or DIDComm flows.
• Assertion — signing claims about the subject (e.g. profile attestations, work-history credentials).

BoxOwl signs claims server-side using the user's encrypted private key when the user authorizes a presentation.

Verifying a BoxOwl identity from outside

The minimal verification flow for a third-party verifier:

1. Take the DID (e.g. did:web:boxowl.me/user:alice).
2. Convert to the resolution URL (https://boxowl.me/did/user/alice).
3. GET that URL over HTTPS — the TLS chain attests that the response really came from boxowl.me.
4. Read the publicKeyMultibase from verificationMethod.
5. Verify any signed payload (e.g. a profile snapshot, a verifiable credential) using that public key with Ed25519.

No BoxOwl-specific SDK is required — any W3C-DID-compliant tooling (e.g. didkit, did-resolver + web-did-resolver on Node.js) will resolve and verify the same documents.

Key rotation

The domain key is rotated by BoxOwl operations on a documented schedule. The previous key remains advertised under previousKeyAgreement while signatures from the rotation window are still validatable.

What's intentionally not here

• No blockchain. did:web is HTTPS-anchored. The platform's trust root is its TLS cert plus the DNS for boxowl.me.
• No discovery directory. If you don't already know a user's handle or UID, did:web can't help you find them. Discovery lives at /api/v1/search.
• No revocation list. Account deletion makes the user's DID resolve as 404, which is the W3C-recommended way to signal a deactivated DID for did:web.

Reference links

• W3C DID Core specification
• did:web method specification