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.
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.
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/psqrIf 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/aliceServer 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.
The namestring that shall identify this DID method is: psqr
.
A DID that uses this method MUST begin with the following prefix:
did:psqr
.
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.
The following steps MUST be executed to resolve the DID document from a PSQR DID:
https://
to the DID method specific identifier.
/.well-known/psqr
.
accept
HTTP
request header. "application/json,application/did+json"
is an
acceptable value.
GET
request to the URL.
One following media types MUST BE used for PSQR DIDs:
application/did+json didjson application/json json
DID operations other than Read are handled out of band as allowed by the core specification.
{ "@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" ] }
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.
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.
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.
The did:psqr
method is intentionally lightweight, and does not
specify auditability or document integrity.
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.