PSQR: Decentralized Identifiers for Public Squares


Abstract

Public Square (PSQR) Decentralized Identifiers are used to sign content for distribution on Public Square networks. The signatures are used to verify the source of portable content against self-hosted, self-certified identity as expressed in PSQR DIDs.

PSQR DIDs are accessible via HTTPS and rely on the same security protocols used to secure the hosting site. A WordPress plugin will be provided to enable any of the millions of existing WordPress websites to self-host DIDs.

PSQR DID Method Specification

Target System

The target system of the PSQR DID method is the web host identified by the domain name described by the DID method specific identifier when queried through the Domain Name System (DNS). Individual DIDs are served by this web host at URLs found by resolving the method specific identifier to an HTTPS URL.

Target System Operations

PSQR DIDs are returned by webservers. Web applications (like WordPress) may return the DIDs in response to properly formed requests, or the DIDs may be hosted as static files with the .json or .didjson file extension. PSQR DID documents MUST be served with a media type of application/json or application/did+json.

The choice of filename and media extension are left in the hands of each implementation. The filename extension is invisible to clients resolving the DIDs via did:psqr, and the secondary filename and media type are included as an option for those who are already using the standard JSON extension and media type for other purposes.

The well-known URL for an entire domain name is the simplest example:

did:psqr:example.com
-> https://example.com/.well-known/psqr
          
If an optional URL path is specified in addition to the bare domain, the file will be available as the index of the specified directory:
did:psqr:example.com/alice
-> https://example.com/alice
          
Server configuration to support index files, custom media types, and content negotiation to return PSQR DIDs when the HTTP accept request header requires either application/did+json or application/json is left in the capable hands of webserver administrators or application developers. Nontechnical users are encouraged to deploy the WordPress plugin to host DIDs.

Note that the contents of the HTTP accept request header are always required to resolve did:psqr DIDs. This enables a DID to reside at the same URL as a human readable user profile.

Method Name

The namestring that shall identify this DID method is: psqr.

A DID that uses this method MUST begin with the following prefix: did:psqr.

Method-Specific Identifier

The method specific identifier is a fully qualified domain name that is secured by a TLS/SSL certificate with an optional URL path to the DID document or the directory containing the DID document. The formal rules describing valid domain name syntax are described in RFC1035, RFC1123, and RFC2181.

The method specific identifier MUST match the common name used in the SSL/TLS certificate, and it MUST NOT include IP addresses. Port specification is not supported. Directories and subdirectories MAY optionally be included, delimited by colons rather than slashes. Colons in directories and subdirectories MUST be percent encoded, if present, to avoid being translated into slashes.

PSQR Method Specific Identifier Formats:

psqr-did = "did:psqr:" domain-name
psqr-did = "did:psqr:" domain-name ? (path)
        

Example PSQR Method DIDs:

did:psqr:example.com
did:psqr:example.com/alice
        

Note that the path referenced above is a standard RFC 3986 URI path that appears as the DID path and also as the HTTPS path.

Note that the domain-name referenced above is the HTTPS authority element. Colons will break DID parsing. IPv6, TCP port specification, and any other use of the colon character is not supported.

DID Method Operations

Read (Resolve)

The following steps MUST be executed to resolve the DID document from a PSQR DID:

  1. Generate an HTTPS URL to the expected location of the DID document by prepending https:// to the DID method specific identifier.
  2. Append the DID path, if it is not zero-length and it is not `/`.
  3. If no DID path was appended, append /.well-known/psqr.
  4. The client MUST specify the DID media types in the accept HTTP request header. "application/json,application/did+json" is an acceptable value.
  5. The client SHOULD NOT follow HTTP 3xx redirects.
  6. Perform an HTTPS GET request to the URL.

One following media types MUST BE used for PSQR DIDs:

          application/did+json                  didjson
          application/json                      json
        

Create, Update, Deactivate (Revoke)

DID operations other than Read are handled out of band as allowed by the core specification.

Example DID Document


{
    "@context": [
      "https://www.w3.org/ns/did/v1",
      "https://vpsqr.com/ns/did-psqr/v1",
      "https://w3id.org/security/suites/jws-2020/v1"
    ],
    "id": "did:psqr:example.com/user",
    "verificationMethod": [
      {
        "id": "did:psqr:example.com/user#z6MknuE5gD3VNy1vkJsQynZzDbPGRKturoxiMeXpMLTw6iWU",
        "type": "JsonWebKey2020",
        "controller": "did:psqr:example.com/user",
        "publicKeyJwk": {
          "kty": "OKP",
          "crv": "Ed25519",
          "x": "fYRgLbA8NxUwu8jm-DguH8U7U1_ycTQms4xToC65v5k"
        }
      },
      {
        "id": "did:psqr:example.com/user#z6LStqsASqk1dcZ2tTckQ6yUfEkf4jSCD1MCSKmuj8SCwNGq",
        "type": "JsonWebKey2020",
        "controller": "did:psqr:example.com/user",
        "publicKeyJwk": {
          "kty": "OKP",
          "crv": "X25519",
          "x": "_xIhtUpp-iQNkWFEZcSSvZFH-2JRpUs0glIzoM9L2Qo"
        }
      }
    ],
    "assertionMethod": [
      "did:psqr:example.com/user#z6MknuE5gD3VNy1vkJsQynZzDbPGRKturoxiMeXpMLTw6iWU"
    ],
    "authentication": [
      "did:psqr:example.com/user#z6MknuE5gD3VNy1vkJsQynZzDbPGRKturoxiMeXpMLTw6iWU"
    ],
    "capabilityInvocation": [
      "did:psqr:example.com/user#z6MknuE5gD3VNy1vkJsQynZzDbPGRKturoxiMeXpMLTw6iWU"
    ],
    "capabilityDelegation": [
      "did:psqr:example.com/user#z6MknuE5gD3VNy1vkJsQynZzDbPGRKturoxiMeXpMLTw6iWU"
    ],
    "keyAgreement": [
      "did:psqr:example.com/user#z6LStqsASqk1dcZ2tTckQ6yUfEkf4jSCD1MCSKmuj8SCwNGq"
    ]
  }
      

Privacy Considerations

Public by Design

The PSQR DID use case is explicitly public. These DIDs are used to attach provenance to content contributed to the public square. There is no expectation of privacy - indeed there is an expectation and intention that the content signed with keys in PSQR DIDs will be exposed to the public.

HTTPS Privacy Considerations

Reads of did:psqr DIDs have the same tracking characteristics as regular HTTPS traffic. Implementers are strongly encouraged to host DIDs on their own domains using systems they control to minimize external tracking.

Cloud delivery services and CDNs that terminate SSL are intermediaries that have visibility into HTTPS requests. Universal resolvers have visibility into DID resolution requests. Browsers and client-facing DNS servers have visibility into domain name resolution requests. Implementers should carefully consider the entire lifecycle of DID resolution and HTTPS delivery when selecting a delivery stack.

Security Considerations

Webserver Security Considerations

In general, did:psqr DIDs will typically be no more secure than the website hosting them. In the specific case of an implementation using the WordPress plugin, the DIDs hosted will be no more secure than the WordPress site.

Auditability, Document Integrity Not Supported

The did:psqr method is intentionally lightweight, and does not specify auditability or document integrity.

Programmatic DID Management Not Specified

Creating, updating, and deleting or revoking the DID documents is left entirely in the hands of the implementers. This is a conscious choice and is driven by the anticipated use case, which involves integration with existing content management systems, notably WordPress.