§ ToIP did:webs Method Specification

Specification Status: v0.10.3

In order to further validate and improve the specification and to demonstrate interoperability between multiple implementations of did:webs, we encourage additional did:webs implementations to the original did:webs Reference Implementation.

Latest Draft:

https://github.com/trustoverip/kswg-did-method-webs-specification

Editors:

• Phil Feairheller, GLEIF
• Daniel Hardman, Provenant, Inc
• Sam Smith, Prosapien
• Lance Byrd, GLEIF and RootsID
• Jonathan Rayback, Future Forge Innovation LLC
• Kent Bull, Kent Bull

Contributors:

• Markus Sabadello, Danube Tech and DIF
• Kevin Griffin, GLEIF
• Charles Lanahan
• Nuttawut Kongsuwan, Finema
• Darrell O’Donnell, Continuum Loop Inc.
• Henk van Cann, Blockchainbird

Participate:

GitHub repo

Commit history

§ Introduction

did:webs:example.com%3a3000:users:alice:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP
│        │          │       │     │     │
│        │          │       │     │     └─ AID (KERI identifier)
│        │          │       │     └─────── Path component
│        │          │       └───────────── Path component
│        │          └───────────────────── Port (URL-encoded)
│        └──────────────────────────────── Host
└───────────────────────────────────────── Method

§ Status of This Memo

Information about the current status of this document, any errata, and how to provide feedback on it, may be obtained at https://github.com/trustoverip/kswg-did-method-webs-specification.

§ Copyright Notice

This specification is subject to the OWF Contributor License Agreement 1.0 - Copyright available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owf-contributor-license-agreement-1-0-copyright.

If source code is included in the specification, that code is subject to the Apache 2.0 license unless otherwise marked. In the case of any conflict or confusion between the OWF Contributor License and the designated source code license within this specification, the terms of the OWF Contributor License MUST apply.

These terms are inherited from the Technical Stack Working Group at the Trust over IP Foundation. Working Group Charter.

§ Terms of Use

These materials are made available under and are subject to the OWF CLA 1.0 - Copyright & Patent license. Any source code is made available under the Apache 2.0 license.

THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series (“ToIP”), and its members and contributors (each of ToIP, its members and contributors, a “ToIP Party”) expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

§ Scope

This document specifies a DID Method, did:webs, that is web-based but innovatively secure. Like its interoperable cousin, did:web, the did:webs method uses traditional web infrastructure to publish DIDs and make them discoverable. Unlike did:web, this method’s trust is not rooted in DNS, webmasters, X509, and certificate authorities. Instead, it uses KERI to provide a secure chain of cryptographic key events by those who control the identifier including any of its delegators.

The did:webs method does not need blockchains to establish trust. However, its use of KERI allows for arbitrary blockchains to be referenced as an extra, optional publication mechanism. This offers a potential interoperability bridge from (or between) blockchain ecosystems. Also, without directly supporting environments where the web is not practical (e.g., IOT, Lo-Ra, Bluetooth, NFC), the method builds on a foundation that can fully support those environments, making future interop of identifiers between web and non-web a manageable step for users of did:webs identifiers.

All DID methods make tradeoffs. The ones in did:webs result in a method that is cheap, easy to implement, and scalable. No exotic or unproven cryptography is required. Deployment is straightforward. Cryptographic trust is strongly decentralized and governance is transparent. Signing authority is scalable through the support of delegated identifiers. Regulatory challenges around the issue of blockchains vanish. Any tech community or legal jurisdiction can use it. However, did:webs does depend on the web for publication and discovery. This may color its decentralization and privacy. For its security, it adds KERI. For users, the method also raises the bar of accountability, thoughtfulness, and autonomy; this can be viewed as either a drawback or a benefit (or both).

§ Normative references

The normative documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

• ISO/IEC 7498-1:1994 Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model, including Requirement Levels (IETF RFC-2119).

See Bibliography - Normative Section

§ Terms and Definitions

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at http://www.electropedia.org/

:::

AID controlled identifier (AID-controlled-identifiers)

Any identifier, including did:webs DIDs, that have the same AID are by

definition referencing the same identity. As defined in the KERISuite

glossary: designated aliases

authentic chained data container (ACDC, ACDCs, authentic-chained-data-container)

a variant of Verifiable Credentials Data Model that

inherits the security model derived from KERI, as defined by the

ACDC specification.

See [[xref: keri1, authentic-chained-data-container, authentic chained data

container]] in the KERISuite glossary for more detail.

autonomic identifier (AID, AIDs, autonomic-identifier)

BADA-RUN

Best available data acceptance - Read/Update/Nullify provides a medium level

of security because events are ordered in a consistent way, using a

combination of date-time and a key state. The latest event is the one with

the latest date-time for the latest key state.

More detail:

The KERI spec.

compact event streaming representation (CESR, compact-event-streaming-representation)

An encoding format that enables round-trip text-binary conversion of

concatenated cryptographic primitives and general data types, as defined by

the CESR specification and

the CESR Proof Signatures specification.

More detail:

CESR.

controller

cryptographically verifiable (cryptographically-verifiable)

decentralized identifier (Decentralized Identifiers, DID, DIDs, decentralized-identifier)

A globally unique persistent identifier, as defined by

DID Core.

designated aliases (designated alias, designated-aliases)

An array of AID controlled identifiers that have been designated by

the AID controller to be used as aliases for equivalentId and

alsoKnownAs DID document metadata and to foster verification of

redirection to different did:webs identifiers.

More detail:

designated aliases.

DID document (DID documents, DID-document)

A set of data describing the subject of a decentralized identifier

(DID), as defined by

DID Core. See also

section DID Documents.

DID document metadata (DID-document-metadata)

DID document metadata is metadata about the DID and the DID document

that is the result of the DID Resolution process.

See also:

DID Document Metadata

in the DID Core specification.

DID resolution metadata (DID-resolution-metadata)

DID resolution metadata is metadata about the DID Resolution process that

was performed in order to obtain the DID document for a given DID.

See also:

DID Resolution Metadata

in the DID Core specification.

direct mode (direct-mode)

hosts (host name, host names, host)

The part of a URL that can be either a domain name or an IP address. This

component specifies the server that the client needs to communicate with in

order to access the desired resource on the web.

identifier

A single attribute—typically a character string—that uniquely identifies an

entity within a specific context (which may be a global context). Examples

include the name of a party, the URL of an organization, or a serial number

for a man-made thing.

Supporting definitions:

*General IT: identifier,

identifier~* Trust-over-IP: identifier.

inception event (inception events, inception-event)

indirect mode (indirect-mode)

interaction event (interaction events, interaction-event)

KEL backed data (KEL-backed-data)

KEL backed data in did:webs provides the highest level of data

security assurance and such data can be found either in the KEL or anchored

to an event in the KEL. This means that the signatures on the events in the

KEL are strongly bound to the key state at the time the events are entered

in the KEL, that is the data.

Explanation: This provides strong guarantees of non-duplicity to any

verifiers receiving a presentation as the KELs are protected and can be

watched by agents (watcher) of the verifiers. The information is

end-verifiable and any evidence of duplicity in the events is evidence that

the data or presentation should not be trusted.

More detail:

WebOfTrust glossary.

KERI event stream (KERI event streams, KERI-event-stream)

A stream of verifiable KERI data, consisting of the key event log

(KEL) and other data such as a transaction event log

(TEL). This data is a CESR event stream, with media type

application/cesr,

and may be serialized in a file using CESR encoding. We refer to

these CESR stream resources as KERI event streams to simplify the vocabulary.

More detail:

KERI event stream.

KERI Request Authentication Mechanism (KRAM, KERI-request-authentication-mechanism)

A non-interactive replay attack protection algorithm that uses a sliding

window of date-time stamps and key state (similar to the tuple in

BADA-RUN) but the date-time is the replier’s not the querier’s.

KRAM is meant to protect a host.

More detail:

WebOfTrust glossary.

key event (key events, key-event)

key event log (KEL, KELs, key-event-log)

key event receipt (key-event-receipt)

key event receipt infrastructure (KERI, key-event-receipt-infrastructure)

key event receipt log (KERL, key-event-receipt-log)

key state (key states, key-state)

method-specific identifier (MSI, method-specific-identifier)

The method-specific-id part of DID Syntax, as defined in

DID Core. See section

Method-Specific Identifier.

Multi-signature (multi-signatures, multisig, multi-sig, multi-signature)

out-of-band introduction (OOBI, OOBIs, OOBI specification, out-of-band-introduction)

Pre-rotation (pre-rotated, pre-rotation)

rotation event (rotation events, rotation-event)

self-addressing identifier (SAID, SAIDs, self-addressing-identifier)

transaction event log (TEL, TELs, transaction-event-log)

verifiable identifier (VID, VIDs, verifiable-identifier)

Verifier (verifiers, verifier)

Watcher (watchers, watcher)

Witness (witnesses, witness)

§ Core Characteristics

This section is normative.

§ Method Name

1. The method name that identifies this DID method SHALL be: webs.
2. A DID that uses this method MUST begin with the following prefix: did:webs:.
3. Per the DID specification, this string MUST be lower case.
4. The remainder of the DID, after the prefix, MUST be the case-sensitive method-specific identifier (MSI) described below.

§ Method-Specific Identifier

1. The did:webs method-specific identifier MUST have two parts, a host with an optional path (identical to did:web), plus a KERI AID (autonomic identifier) that is always the final component of the path.
2. The ABNF definition of a did:webs DID MUST be as follows:

; did:webs DID structure
webs-did = "did:webs:" host [pct-encoded-colon port] *(":" path) ":" aid

; Simplified host character class for illustration only.
; Normative domain-name rules: RFC 1035, RFC 1123, and RFC 2181.
; Normative URI host/authority (including IP forms): RFC 3986.
; Implementations SHOULD use a mature URI/host parsing library.
host = 1*( ALPHA / DIGIT / "-" / "." )

; 'pct-encoded-colon' represents a percent-encoded colon
pct-encoded-colon = "%3A" / "%3a" ; Percent encoding for ':'

; 'port' number (simplified version)
port = 1*5(DIGIT)

; Path segment between colons (no '/'; path separators in the DID are ':')
path = 1*(ALPHA / DIGIT / "-" / "_" / "~" / ".")

aid = said

; AID is a KERI SAID; SAID structure:
said = said-256 / said-512

; Base64URLSafe characters (RFC 4648, excluding padding)
base64urlsafe = ALPHA / DIGIT / "-" / "_"

; The complete SAID primitive MUST conform to the CESR code tables.
; The following currently defined digest codes produce 256-bit or
; 512-bit SAIDs of 44 or 88 characters total.

; 256-bit SAIDs: 44 characters total (1 char code + 43 Base64URLSafe)
one-char-code = "E" / "F" / "G" / "H" / "I"
said-256 = one-char-code 43base64urlsafe

; 512-bit SAIDs: 88 characters total (2 char code + 86 Base64URLSafe)
two-char-code = "0D" / "0E" / "0F" / "0G"
said-512 = two-char-code 86base64urlsafe

1. When the host is a domain name, it MUST abide by the formal rules describing valid domain name syntax found in RFC 1035, RFC 1123, and RFC 2181.
2. When interpreting the host as part of a URI authority — including port handling and IP-literal forms — the host MUST also conform to the host production in RFC 3986. Implementations SHOULD use a mature URI/host parsing library rather than relying solely on the simplified ABNF host rule above.
3. A port MAY be included and the colon MUST be percent encoded, like %3a, to prevent a conflict with paths.
4. Directories and subdirectories MAY optionally be included, delimited by colons rather than slashes. Path segments MUST NOT contain /.
5. The KERI AID is a unique identifier and MUST be derived from the inception event of a KERI identifier.

§ Target System(s)

1. As with did:web, did:webs MUST read data from whatever web server is referenced when the host portion of one of its DIDs is resolved.
2. A did:webs DID MUST resolve to a DID document using a simple text transformation to an HTTPS URL in the same way as a did:web DID.
3. A did:web DID and did:webs DID with the same method-specific-identifier SHOULD return the same DID document, except for minor differences in the id, controller, and alsoKnownAs top-level properties that pertain to the identifiers themselves.
4. As with did:web, the location of the did:webs DID document MUST be determined by transforming the DID to an HTTPS URL as follows:
   1. MUST replace did:webs with https://
   2. MUST replace the ":"s in the method-specific identifier with path separators, "‘/’"s
   3. MUST convert the optional port percent encoding (%3A or %3a) to a colon if present.
   4. MUST append “/did.json” to the resulting string.
5. A GET on that URL MUST return the DID document.
6. The location of the KERI event stream MUST be determined by transforming the previous URL as follows:
   1. MUST replace the trailing “/did.json” with “/keri.cesr”.
   2. A GET on that URL MUST return the KERI event stream for the AID in the did:webs identifier.
   3. The KERI event stream MUST be CESR-formatted, MUST have the media type of application/cesr, and the KERI events MUST be verifiable using the KERI rules.
7. The did:web version of the DIDs MUST be the same (minus the s) and point to the same did.json file.

§ Sample did:webs URLs

§ KERI puts the “s” in did:webs

§ AID controlled identifiers

1. AID controlled identifiers MAY vary in how quickly they reflect the current identity information, DID document and KERI event stream. Notably, as defined in section Stable Identifiers On An Unstable Web, the id property in the DID document will differ based on the web location of the DID document.
2. Different versions of the DID document and KERI event stream MAY reside in different locations depending on the replication capabilities of the controlling entity.
3. If the KERI event streams differ for did:webs DIDs with the same AID, the smaller KERI event stream MUST be a prefix of the larger KERI event stream (e.g., the only difference in the KERI event streams being the extra events in one of the KERI event streams, not yet reflected in the other).
4. If the KERI event streams diverge from one another (e.g., one is not a subset of the other), both the KERI event streams and the DIDs MUST be considered invalid.
5. The verification of the KERI event stream SHOULD provide mechanisms for detecting the forking of the KERI event stream by using mechanisms such as KERI witnesses and watchers.

§ Handling Web Redirection

1. A did:webs DID MAY be a “stable” (long-lasting) identifier that can be put into documents such as verifiable credentials, to be useful for a very long time – generations.

2. When a did:webs DID is updated for another location the following rules MUST apply:

   1. Its AID MUST NOT change.
   2. The same KERI event stream MUST be used to verify the DID document, with the only change being the designated aliases list reflecting the new location identifier.
   3. If a resolver can find a newly named DID that uses the same AID, and the KERI event stream verifies the DID, then the resolver MAY consider the resolution to be successful and should note it in the resolution metadata.

3. The following resolution paths that did:webs identifiers SHALL leverage to help in the face of resolution uncertainty include:

   1. The did:webs DID SHALL provide other designated aliases DID(s) that are anchored to the KERI event stream.
   2. When a did:webs DID is permanently moved to some other location the resolver MAY redirect to any other equivalentId designated aliases.
      1. The id in the DID document MUST be set to the new location.
      2. An equivalentId entry of the old location SHOULD remain for historical purposes and be anchored to the KERI event stream using designated aliases. See section Use of equivalentId for more details.
      3. If possible, the controller of the DID MAY use web redirects to allow resolution of the old location of the DID to the new location.
   3. If the previously published location of a did:webs DID is not redirected, an entity trying to resolve the DID MAY be able to find the data for the DID somewhere else using just the AID.

§ DID Method Operations

This section is normative.

§ Create

1. Creating a did:webs DID MUST follow these rules:
   1. MUST choose the web URL where the DID document for the DID will be published, excluding the last element that will be the AID, once defined.
   2. MUST create a KERI AID and add it as the last element of the web URL for the DID.
   3. MUST authorize the full did:webs identifier as a designated alias ACDC anchored to the KERI AID (see Method-Specific Identifier).
   4. If desired, a did:web form of the identifier MAY be authorized in the same manner.
   5. MUST add the appropriate KERI events to the AID’s KERI logs that will correspond to properties of the DID document, such as verification methods and service endpoints.
   6. MUST derive the did:webs DID document by processing the KERI event stream according to section DID documents.
   7. For compatibility reasons, transformation of the derived did:webs DID document to the corresponding did:web DID document MUST be according to section Transformation to did:web DID document.
   8. MUST make the did:web DID document resource (did.json) and the KERI event stream resource (keri.cesr) available at the selected location. See section Target System(s) for further details about the locations of these resources.

§ Read (Resolve)

This section is normative.

Resolving a did:webs DID MUST follow the procedure below. If any step fails, the resolver MUST NOT return a DID document as a successful resolution result. When producing a DID Resolution result, the resolver MUST include an error in didResolutionMetadata as specified by DID Resolution and DID Core, leave didDocument empty, and leave didDocumentMetadata empty.

1. Convert the did:webs DID to the HTTPS URLs for did.json and keri.cesr as described in Target System(s). If the DID is not a valid did:webs identifier, resolution MUST fail.
2. Perform HTTP GET on both URLs.
   1. If either request fails to return a successful response with a usable body, resolution MUST fail.
   2. The did.json resource MUST be a did:web DID document suitable for transformation under Transformation to did:webs DID document (published per Transformation to did:web DID document).
   3. The keri.cesr resource MUST be a CESR-formatted KERI event stream with media type application/cesr.
3. Process keri.cesr according to the KERI specification.
   1. If cryptographic verification fails, resolution MUST fail.
   2. If event-stream divergence or forking is detected (see AID controlled identifiers), resolution MUST fail.
   3. If an optional versionId DID parameter is present, only events up to and including that sequence number MUST be used for the remainder of this procedure (see Support for versionId).
4. Confirm that a valid, unrevoked designated aliases ACDC in the KERI event stream as limited by step 3 authorizes the resolved did:webs DID and the corresponding did:web DID. If not, resolution MUST fail. See Designated Aliases and Use of equivalentId.
5. Derive the did:webs DID document from the verified KERI event stream according to DID documents.
6. Transform the fetched did:web DID document to a did:webs DID document according to Transformation to did:webs DID document. If the transformation cannot be applied, resolution MUST fail.
7. The derived DID document MUST equal the transformed DID document. If they differ, resolution MUST fail.
8. Return the did:webs DID document, together with any DID document metadata required by this specification (for example versionId and, when applicable, equivalentId and nextVersionId).

§ Update

The did:webs identifier string itself — host, path, and AID — MUST NOT change. Updates change content derived from the KERI event stream (keys, aliases, and service endpoints) and MUST be reflected by regenerating and republishing did.json and keri.cesr as soon as practical. If the resources are statically hosted, they MUST be overwritten at the published location.

§ Key rotation update

1. If the AID of the did:webs DID is transferable, key rotation updates MUST be made by adding KERI key rotation events to the KERI event stream.
2. Rotating keys MUST change the keys that appear in the DID document and MUST NOT change the identifier (AID).

Note: the versionId query parameter is not part of the identifier. It may be used to request a point-in-time version of a DID document as of a given KERI key event sequence number. See Support for versionId.

§ Designated alias update

1. Updates that add, remove, or replace authorized aliases (affecting alsoKnownAs and equivalentId) MUST be performed by revoking and/or issuing designated aliases ACDCs anchored to the KERI event stream, according to section Designated Aliases.
2. After the KERI event stream reflects the updated aliases, the controller MUST regenerate the DID document and republish did.json and keri.cesr.

§ Service endpoint update

1. Updates that change witness lists, Location Scheme records, or Endpoint Role Authorization records MUST be performed by adding the corresponding KERI events (rotation events for witness lists; rpy events for Location Scheme and Endpoint Role Authorization) to the KERI event stream, according to section Service Endpoint Event Details.
2. After the KERI event stream reflects the updated endpoints, the controller MUST regenerate the DID document and republish did.json and keri.cesr.

§ Deactivate

1. To deactivate a did:webs DID, a controller MUST execute a KERI event that has the effect of rotating the key(s) to null (or otherwise committing to no next keys), rendering the AID non-transferable.
2. Once the deactivation event has been applied, the controller MUST regenerate the DID document from the KERI event stream and republish both did.json and keri.cesr at the published location, overwriting the existing files, so that resolvers can discover the deactivated state.
3. A controller MUST NOT make the DID document or KERI event stream resources unavailable at the location where they have been published.
   INFORMATIVE SECTION

   Removing the DID resources prevents resolvers from distinguishing an offline host from a deactivated DID. Keeping the deactivated artifacts published preserves end-verifiable evidence of deactivation.

§ DID documents

This section is normative.

1. did:webs DID documents MUST be generated or derived from the KERI event stream of the corresponding AID.
   1. Processing the KERI event stream of the AID, the generation algorithm MUST read the AID KEL and any anchored TELs to produce the DID document, including any designated alias ACDCs.
2. did:webs DID documents MUST be pure JSON. They MAY be processed as JSON-LD by prepending an @context if consumers of the documents wish.
3. All hashes, cryptographic keys, and signatures MUST be represented as CESR strings. This is an approach similar to multibase, making them self-describing and terse.

{
    "v": "KERI10JSON000274_",
    "i": "EeS834LMlGVEOGR8WU3rzZ9M6HUv_vtF32pSXQXKP7jg",
    "s": "1",
    "t": "ksn",
    "p": "ESORkffLV3qHZljOcnijzhCyRT0aXM2XHGVoyd5ST-Iw",
    "d": "EtgNGVxYd6W0LViISr7RSn6ul8Yn92uyj2kiWzt51mHc",
    "f": "1",
    "dt": "2021-11-04T12:55:14.480038+00:00",
    "et": "ixn",
    "kt": "1",
    "k": ["DTH0PwWwsrcO_4zGe7bUR-LJX_ZGBTRsmP-ZeJ7fVg_4"],
    "nt": 1,
    "n": ["E6qpfz7HeczuU3dAd1O9gPPS6-h_dCxZGYhU8UaDY2pc"],
    "bt": "3",
    "b": [
      "BGKVzj4ve0VSd8z_AmvhLg4lqcC_9WYX90k03q-R_Ydo",
      "BuyRFMideczFZoapylLIyCjSdhtqVb31wZkRKvPfNqkw",
      "Bgoq68HCmYNUDgOz4Skvlu306o_NY-NrYuKAVhk3Zh9c"
    ],
    "c": [],
    "ee": {
      "s": "0",
      "d": "ESORkffLV3qHZljOcnijzhCyRT0aXM2XHGVoyd5ST-Iw",
      "br": [],
      "ba": []
    },
    "di": ""
}

§ DID Subject

This section is normative.

1. The value of the id property in the DID document MUST be the did:webs DID that is being created or resolved.
2. The value from the i field of the key state notice MUST be the value after the last : in the method-specific identifier (MSI) of the did:webs DID, per section Method-Specific Identifier.

{
  "id": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M"
}

§ DID Controller

This section is normative.

1. The value of the controller property MUST be a single string that is the same as the id (the DID Subject).

{
  "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M"
}

§ Also Known As

This section is normative.

1. The alsoKnownAs property in the root of the DID document MAY contain any DID that has the same AID.

   INFORMATIVE SECTION

   See the designated aliases section for information on how an AID anchors the alsoKnownAs identifiers to their KERI event stream.

   1. As long as the identifier is resolvable, a designated alias ACDC containing a given identifier MUST always be present in the keri.cesr stream in order for any identifier to be included in the alsoKnownAs section of a did:webs DID document.
      INFORMATIVE SECTION

      Presence of designated alias ACDCs containing both did:webs and did:web identifiers are required to support the transformation rules between did:webs and did:web versions of a did:webs DID document while adhering to the security posture of KERI and ACDC.

      One potential way to implement this requirement is to ensure that resolving a given version of a did:webs DID document via the versionId parameter will return the DID document as of a given sequence number by analyzing the designated aliases ACDCs that were valid and unrevoked at that time.

2. The did:webs version of the DID document MAY include the did:web version of the DID as an alsoKnownAs identifier, provided that there is a valid, unrevoked designated aliases ACDC present in the keri.cesr stream.

3. The did:web version of the DID document MUST include the did:webs version of the DID as an alsoKnownAs identifier, meaning it MUST also be in a valid, unrevoked designated aliases ACDC present in the keri.cesr stream.

4. In order for the did:webs DID document to be valid, the keri.cesr stream MUST contain at least ONE designated aliases ACDC in which the host and path are committed to.

   INFORMATIVE SECTION

   Committed to means placed in a designated aliases ACDC.

   This implies that the did.json for both the did:webs and did:web versions of a did:webs DID document will always contain a reciprocal link to one another that is also committed to by an event anchored into the KEL of the DID controller.

   A consumer of a DID document can only know that a given did:web DID is trustable and committed to by the controller of the AID supporting a did:webs DID only when that did:web DID is included in an unrevoked designated aliases ACDC.

   This protects against DID document malleability attacks where a malicious DID resolver host could inject fraudulent did:web DIDs into a DID document. As such, the consumer of a did:webs DID document should only trust did:web DIDs that are found in an unrevoked designated aliases ACDC present in the keri.cesr stream.

5. did:webs DIDs MUST provide the corresponding did:keri as an alsoKnownAs identifier.

6. The same AID MAY be associated with multiple did:webs DIDs, each with a different host and/or path, but with the same AID.

7. did:webs DIDs MUST be listed in the Designated aliases attestation of the AID.

8. For each AID controlled identifier DID defined above, an entry in the alsoKnownAs array in the DID document MUST be created.

{
  "alsoKnownAs": [
    "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "did:keri:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
  ]
}

§ Verification Methods

This section is normative.

Each verification method for a did:webs DID is generated from signing keys located in the KERI event stream of the controller of the did:webs DID.

1. For each key listed in the array value of the k field of the KSN, a corresponding verification method MUST be generated in the DID document.

2. The type property in the verification method for each public key MUST be determined by the algorithm used to generate the public key, as specified in the following subsections.

3. The id property of the verification method MUST be a relative DID URL and use the KERI key CESR value as the value of the fragment component, e.g., "id": "#<identifier>".

4. The controller property of the verification method MUST be the value of the id property of the DID document.

   INFORMATIVE SECTION

   DID Core requires each verification method to have a controller property whose value is a valid DID, but does not require that value to equal the id of the DID document (e.g., delegation may use a different controller). This specification requires that for did:webs the controller of every verification method equals the document id, since all verification material is derived from the same AID’s key state.

  "verificationMethod": [
    {"id": "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
    "type": "JsonWebKey",
    "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe", 
    "publicKeyJwk": {
      "kid": "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr", 
      "kty": "OKP", 
      "crv": "Ed25519", 
      "x": "evT4j6Yw3uHpwsw5NEmSR8-4x3S-BA-s6Thjd51oeOs"
      }
    }
  ]

§ Ed25519

1. Ed25519 public keys MUST be converted to a verification method with a type of JsonWebKey and publicKeyJwk property whose value is generated by decoding the CESR representation of the public key out of the KEL and into its binary form (minus the leading ‘B’ or ‘D’ CESR codes) and generating the corresponding representation of the key in JSON Web Key form.

For example, a KERI AID with only the following inception event in its KEL:

{
  "v":"KERI10JSON00012b_",
  "t":"icp",
  "d":"ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
  "i":"ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
  "s":"0",
  "kt":"1",
  "k":["DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"],
  // ...
}

would result in a DID document with the following verification methods array:

"verificationMethod": [
  {
    "id": "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr", 
    "type": "JsonWebKey", 
    "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe", 
    "publicKeyJwk": {
      "kid": "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr", 
      "kty": "OKP", 
      "crv": "Ed25519", 
      "x": "evT4j6Yw3uHpwsw5NEmSR8-4x3S-BA-s6Thjd51oeOs"
      }
  }
]

§ Secp256k1

1. Secp256k1 public keys MUST be converted to a verification method with a type of JsonWebKey and publicKeyJwk property whose value is generated by decoding the CESR representation of the public key out of the KEL and into its binary form (minus the leading ‘1AAA’ or ‘1AAB’ CESR codes) and generating the corresponding representation of the key in JSON Web Key form.

For example, a KERI AID with only the following inception event in its KEL:

{
  "v": "KERI10JSON0001ad_",
  "t": "icp",
  "d": "EDP1vHcw_wc4M__Fj53-cJaBnZZASd-aMTaSyWEQ-PC2",
  "i": "EDP1vHcw_wc4M__Fj53-cJaBnZZASd-aMTaSyWEQ-PC2",
  "s": "0",
  "kt": "1",
  "k": [
    "1AAAAmbFVu-Wf8NCd63B9V0zsy7EgB_ocX2_n_Nh1FCmgF0Y",
  ]
  // ...
}

would result in a DID document with the following verification methods array:

  "verificationMethod": [
    {
      "id": "#1AAAAmbFVu-Wf8NCd63B9V0zsy7EgB_ocX2_n_Nh1FCmgF0Y",
      "type": "JsonWebKey",
      "controller": "did:webs:example.com:EDP1vHcw_wc4M__Fj53-cJaBnZZASd-aMTaSyWEQ-PC2",
      "publicKeyJwk": {
        "kid": "1AAAAmbFVu-Wf8NCd63B9V0zsy7EgB_ocX2_n_Nh1FCmgF0Y",
        "kty": "EC",
        "crv": "secp256k1",
        "x": "ZsVW75Z_w0J3rcH1XTOzLsSAH-hxfb-Q82HUUKaAXRg",
        "y": "Lu6Uw785U3K05D-NPNoUInHPNUz9cGqWwjKjm5KL8FI"
      }
    }
  ]

§ Secp256r1

1. Secp256r1 public keys MUST be converted to a verification method with a type of JsonWebKey and publicKeyJwk property whose value is generated by decoding the CESR representation of the public key out of the KEL and into its binary form (minus the leading ‘1AAI’ or ‘1AAJ’ CESR codes) and generating the corresponding representation of the key in JSON Web Key form.

For example, a KERI AID with only the following inception event in its KEL:

{
  "v": "KERI10JSON0001ad_",
  "t": "icp",
  "d": "EHs9k2mQpL7vNxR4wYtUcA1bZdF3gJhK8mNoPqRsTuVw",
  "i": "EHs9k2mQpL7vNxR4wYtUcA1bZdF3gJhK8mNoPqRsTuVw",
  "s": "0",
  "kt": "1",
  "k": [
    "1AAIKs8mNpQ2vWxYzAbCdEfGhIjKlMnOpQrStUvWxYz01234"
  ]
  // ...
}

would result in a DID document with the following verification methods array:

  "verificationMethod": [
    {
      "id": "#1AAIKs8mNpQ2vWxYzAbCdEfGhIjKlMnOpQrStUvWxYz01234",
      "type": "JsonWebKey",
      "controller": "did:webs:example.com:EHs9k2mQpL7vNxR4wYtUcA1bZdF3gJhK8mNoPqRsTuVw",
      "publicKeyJwk": {
        "kid": "1AAIKs8mNpQ2vWxYzAbCdEfGhIjKlMnOpQrStUvWxYz01234",
        "kty": "EC",
        "crv": "secp256r1",
        "x": "xYz9AbCdEfGhIjKlMnOpQrStUvWx0123456789abcde",
        "y": "yZ0BcDeFgHiJkLmNoPqRsTuVwXyZaBcDeFgHiJkLmNo"
      }
    }
  ]

§ Thresholds

1. If the current signing keys threshold (the value of the kt field) is a string containing a number that is greater than 1, or if it is an array containing fractionally weighted thresholds, then in addition to the verification methods generated according to the rules in the previous sections, another verification method with a type of ConditionalProof2022 MUST be generated in the DID document.

   1. It MUST be constructed according to the following rules:

      1. The id property of the verification method MUST be a relative DID URL and use the AID as the value of the fragment component, e.g., "id": "#<aid>".
      2. The controller property of the verification method MUST be the value of the id property of the DID document.
      3. If the value of the kt field is a string containing a number that is greater than 1 then the following rules MUST be applied:
         1. The threshold property of the verification method MUST be the integer value of the kt field in the current key state.
         2. The conditionThreshold property of the verification method MUST contain an array. For each key listed in the array value of the k field in the key state:
            1. The relative DID URL corresponding to the key MUST be added to the array value of the conditionThreshold property.
      4. If the value of the kt field is an array containing fractionally weighted thresholds then the following rules MUST be applied:
         1. The threshold property of the verification method MUST be the lowest common denominator (LCD) of all the fractions in the kt array.
         2. The conditionWeightedThreshold property of the verification method MUST contain an array. For each key listed in the array value of the k field in the key state, and for each corresponding fraction listed in the array value of the kt field:
            1. A JSON object MUST be added to the array value of the conditionWeightedThreshold property.
            2. The JSON object MUST contain a property condition whose value is the relative DID URL corresponding to the key.
            3. The JSON object MUST contain a property weight whose value is the numerator of the fraction after it has been expanded over the lowest common denominator (LCD) of all the fractions.

      For example, a KERI AID with only the following inception event in its KEL, and with a kt value greater than 1:

      {
        "v": "KERI10JSON0001b7_",
        "t": "icp",
        "d": "Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
        "i": "Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
        "s": "0",
        "kt": "2",  // Signing Threshold
        "k": [
          "1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",  // Secp256k1 Key
          "DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",      // Ed25519 Key
          "DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu"       // Ed25519 Key
        ],
      }
      

      results in a DID document with the following verification methods array:

      {
        "verificationMethod": [
          {
            "id": "#Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "type": "ConditionalProof2022",
            "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "threshold": 2,
            "conditionThreshold": [
              "#1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",
              "#DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",
              "#DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu"
            ]
          },
          {
            "id": "#1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",
            "type": "JsonWebKey",
            "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "publicKeyJwk": {
              "kid": "1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",
              "kty": "EC",
              "crv": "secp256k1",
              "x": "NtngWpJUr-rlNNbs0u-Aa8e16OwSJu6UiFf0Rdo1oJ4",
              "y": "qN1jKupJlFsPFc1UkWinqljv4YE0mq_Ickwnjgasvmo"
            }
          },
          {
            "id": "#DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",
            "type": "JsonWebKey",
            "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "publicKeyJwk": {
              "kid": "DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",
              "kty": "OKP",
              "crv": "Ed25519",
              "x": "A-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE"
            }
          },
          {
            "id": "#DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu",
            "type": "JsonWebKey",
            "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "publicKeyJwk": {
              "kid": "DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu",
              "kty": "OKP",
              "crv": "Ed25519",
              "x": "LWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNws"
            }
          }
        ]
      }
      

      For example, a KERI AID with only the following inception event in its KEL, and a kt containing fractionally weighted thresholds:

      {
        "v": "KERI10JSON0001b7_",
        "t": "icp",
        "d": "Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
        "i": "Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
        "s": "0",
        "kt": ["1/2", "1/3", "1/4"],  // Signing Threshold
        "k": [
          "1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",  // Secp256k1 Key
          "DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",      // Ed25519 Key
          "DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu"       // Ed25519 Key
        ],
      }
      

      would result in a DID document with the following verification methods array:

      {
        "verificationMethod": [
          {
            "id": "#Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "type": "ConditionalProof2022",
            "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "threshold": 12,
            "conditionWeightedThreshold": [
              {
                "condition": "#1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",
                "weight": 6
              },
              {
                "condition": "#DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",
                "weight": 4
              },
              {
                "condition": "#DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu",
                "weight": 3
              }
            ]
          },
          {
            "id": "#1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",
            "type": "JsonWebKey",
            "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "publicKeyJwk": {
              "kid": "1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",
              "kty": "EC",
              "crv": "secp256k1",
              "x": "NtngWpJUr-rlNNbs0u-Aa8e16OwSJu6UiFf0Rdo1oJ4",
              "y": "qN1jKupJlFsPFc1UkWinqljv4YE0mq_Ickwnjgasvmo"
            }
          },
          {
            "id": "#DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",
            "type": "JsonWebKey",
            "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "publicKeyJwk": {
              "kid": "DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",
              "kty": "OKP",
              "crv": "Ed25519",
              "x": "A-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE"
            }
          },
          {
            "id": "#DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu",
            "type": "JsonWebKey",
            "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
            "publicKeyJwk": {
              "kid": "DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu",
              "kty": "OKP",
              "crv": "Ed25519",
              "x": "LWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNws"
            }
          }
        ]
      }
      

§ Verification Relationships

This section is normative.

did:webs commits the same keys for both authentication and assertion, a design facilitated by being built upon KERI. A conforming did:webs DID document MUST include both the authentication and assertionMethod properties, generated according to the rules below. A did:webs DID document MAY also include other verification relationship properties.

1. If the value of kt == 1 then the following rules MUST be applied:
   1. For each public key in k and its corresponding verification method, the DID document MUST include that verification method in both authentication and assertionMethod.
      1. The authentication verification relationship SHALL define that the DID controller can authenticate using each key.
      2. The assertionMethod verification relationship SHALL define that the DID controller can express claims using each key.
2. If the value of kt > 1 or if the value of kt is an array containing fractionally weighted thresholds then the following rules MUST be applied:
   1. For the verification method of type ConditionalProof2022 (see section Thresholds), the DID document MUST include that verification method in both authentication and assertionMethod.
      1. The authentication verification relationship SHALL define that the DID controller can authenticate using a combination of multiple keys above the threshold.
      2. The assertionMethod verification relationship SHALL define that the DID controller can express claims using a combination of multiple keys above the threshold.
3. References to verification methods in the DID document MUST use the relative form of the identifier, e.g., "authentication": ["#<identifier>"].

For example, a KERI AID with only the following inception event in its KEL:

{
  "v":"KERI10JSON00012b_",
  "t":"icp",
  "d":"ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
  "i":"ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
  "s":"0",
  "kt":"1",
  "k":["DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"],
  // ...
}

would result in a DID document with the following verification methods array and verification relationships:

"verificationMethod": [
  {
    "id": "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr", 
    "type": "JsonWebKey", 
    "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe", 
    "publicKeyJwk": {
      "kid": "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr", 
      "kty": "OKP", 
      "crv": "Ed25519", 
      "x": "evT4j6Yw3uHpwsw5NEmSR8-4x3S-BA-s6Thjd51oeOs"
      }
  }
],
"authentication": [
  "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
],
"assertionMethod": [
  "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
]

§ Service Endpoints

This section is normative.

1. did:webs DIDs MUST support service endpoints, including types declared in the DID Specification Registries, such as DIDCommMessaging.

§ KERI Service Endpoints as DID document metadata

1. did:webs endpoints MUST be specified using the two data sets KERI uses to define service endpoints: Location Schemes and Endpoint Role Authorizations.

   1. Both MUST be expressed in KERI rpy events.
   2. For URL scheme endpoints that an AID has exposed, did:webs DIDs MUST use Location Schemes URLs.
   3. For endpoints that relate a role of one AID to another, did:webs DIDs MUST use KERI Endpoint Role Authorizations.

   For example, the following rpy method declares that the AID EIDJUg2eR8YGZssffpuqQyiXcRVz2_Gw_fcAVWpUMie1 exposes the URL http://127.0.0.1:3901/ for scheme http:

   {
       // ...
       "t": "rpy",
       "r": "/loc/scheme",
       "a": {
         "eid": "EIDJUg2eR8YGZssffpuqQyiXcRVz2_Gw_fcAVWpUMie1",
         "scheme": "http",
         "url": "http://127.0.0.1:3901/"
       }
     }
   

   For example, the AID listed in cid is the source of the authorization, the role is the role and the AID listed in the eid field is the target of the authorization. So in this example EOGL1KGpOnRaZDIB11uZDCkhHs52_MtMXHd7EqUqwtA3 is being authorized as an Agent for EIDJUg2eR8YGZssffpuqQyiXcRVz2_Gw_fcAVWpUMie1.

   {
       // ...
       "t": "rpy",
       "r": "/end/role/add",
       "a": {
         "cid": "EIDJUg2eR8YGZssffpuqQyiXcRVz2_Gw_fcAVWpUMie1",
         "role": "agent",
         "eid": "EOGL1KGpOnRaZDIB11uZDCkhHs52_MtMXHd7EqUqwtA3"
       }
   }
   

2. KERI service endpoints roles beyond witness SHOULD be defined using Location Scheme and Endpoint Authorization records in KERI. See the KERI specification for more information about KERI roles.

§ Transformation to did:web DID document

This section is normative.

When transforming a did:webs DID document to the corresponding did:web DID document the following rules determine what MUST change to make a valid, transformed did:web version of the did:webs DID document.

1. A conforming implementation MUST NOT perform this transformation unless a valid, unrevoked designated aliases ACDC in the KERI event stream authorizes both the did:webs subject DID and the corresponding did:web DID formed by replacing the did:webs prefix with did:web. See Designated Aliases and Also Known As.

1. Transformation of the did:webs form of the DID document to a did:web DID document MUST do the following:

   1. Starting from the top-level id (a did:webs DID), form the corresponding did:web DID by replacing the did:webs prefix with did:web.
   2. The top-level id and controller property values MUST be set to that corresponding did:web DID.
   3. For every verificationMethod entry whose controller equals the original did:webs subject DID, the controller MUST be set to the corresponding did:web DID.
   4. The alsoKnownAs array MUST replace the corresponding did:web entry with the original did:webs subject DID, so the transformed document lists the did:webs form as an alias of the did:web subject.
   5. All other content of the DID document MUST NOT be modified.

   For example, this transformation is used during the Create DID method operation, given the following did:webs DID document:

   {
       "id": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
       "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
       "verificationMethod": [
           {
               "id": "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
               "type": "JsonWebKey",
               "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
               "publicKeyJwk": {
                   "kid": "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
                   "kty": "OKP",
                   "crv": "Ed25519",
                   "x": "evT4j6Yw3uHpwsw5NEmSR8-4x3S-BA-s6Thjd51oeOs"
               }
           }
       ],
       "authentication": [
         "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
       ],
       "assertionMethod": [
         "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
       ],
       "service": [],
       "alsoKnownAs": [
           "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
           "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
           "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
           "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
           "did:keri:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
       ]
   }
   

   the result of the transformation algorithm is the following did:web DID document:

   {
     "id": "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
     "controller": "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
     "verificationMethod": [
         {
             "id": "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
             "type": "JsonWebKey",
             "controller": "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
             "publicKeyJwk": {
                 "kid": "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
                 "kty": "OKP",
                 "crv": "Ed25519",
                 "x": "evT4j6Yw3uHpwsw5NEmSR8-4x3S-BA-s6Thjd51oeOs"
             }
         }
     ],
     "authentication": [
       "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
     ],
     "assertionMethod": [
       "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
     ],
     "service": [],
     "alsoKnownAs": [
         "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
         "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
         "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
         "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
         "did:keri:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
     ]
   }
   

§ Transformation to did:webs DID document

This section is normative.

When transforming a did:web DID document to the corresponding did:webs DID document the following rules determine what MUST change to make a valid, transformed did:webs version of the did:web DID document.

1. A conforming implementation MUST NOT perform this transformation unless a valid, unrevoked designated aliases ACDC in the KERI event stream authorizes both the did:web subject DID and the corresponding did:webs DID formed by replacing the did:web prefix with did:webs. An arbitrary did:web DID document MUST NOT be treated as a did:webs DID document merely because its method-specific identifier ends in an AID. See Designated Aliases and Also Known As.

1. Transformation of the did:web DID document to a did:webs DID document MUST do the following:

   1. Starting from the top-level id (a did:web DID), form the corresponding did:webs DID by replacing the did:web prefix with did:webs.
   2. The top-level id and controller property values MUST be set to that corresponding did:webs DID.
   3. For every verificationMethod entry whose controller equals the original did:web subject DID, the controller MUST be set to the corresponding did:webs DID.
   4. The alsoKnownAs array MUST replace the corresponding did:webs entry with the original did:web subject DID, so the transformed document lists the did:web form as an alias of the did:webs subject.
   5. All other content of the DID document MUST NOT be modified.

2. A did:webs resolver MUST use this transformation during the Read (Resolve) DID method operation.

   For example, given the following did:web DID document:

   {
     "id": "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
     "controller": "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
     "verificationMethod": [
         {
             "id": "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
             "type": "JsonWebKey",
             "controller": "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
             "publicKeyJwk": {
                 "kid": "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
                 "kty": "OKP",
                 "crv": "Ed25519",
                 "x": "evT4j6Yw3uHpwsw5NEmSR8-4x3S-BA-s6Thjd51oeOs"
             }
         }
     ],
     "authentication": [
       "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
     ],
     "assertionMethod": [
       "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
     ],
     "service": [],
     "alsoKnownAs": [
         "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
         "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
         "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
         "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
         "did:keri:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
     ]
   }
   

   the result of the transformation algorithm is the following did:webs DID document:

   {
       "id": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
       "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
       "verificationMethod": [
           {
               "id": "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
               "type": "JsonWebKey",
               "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
               "publicKeyJwk": {
                   "kid": "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
                   "kty": "OKP",
                   "crv": "Ed25519",
                   "x": "evT4j6Yw3uHpwsw5NEmSR8-4x3S-BA-s6Thjd51oeOs"
               }
           }
       ],
       "authentication": [
         "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
       ],
       "assertionMethod": [
         "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
       ],
       "service": [],
       "alsoKnownAs": [
           "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
           "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
           "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
           "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
           "did:keri:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
       ]
   }
   

§ Full Example

{
  "v": "KERI10JSON000159_",
  "t": "icp",
  "d": "EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
  "i": "EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP", // controller AID
  "s": "0",
  "kt": "1", // Signing Threshold
  "k": [
    "DJg7AQUSKAEo-Pkgj4tVF7L0-FqJt0QFxFh5878AcZv6" // Ed25519 Key
  ],
  "nt": "1",
  "n": [
    "EIzv5mDvyc-ftAyn06LyO0HvzfG7dJqx1zvYWGGIGiYp"
  ],
  "bt": "1",
  "b": [
    "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q"
  ],
  "c": [],
  "a": []
}
// series of events establishing a witness service
{
    "v": "KERI10JSON00013a_",
    "t": "ixn",
    "d": "EMllQ2kDZp9OnErTfJkzqbZN4hoH-rATBvVyASczJFIN",
    "i": "EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
    "s": "1",
    "p": "EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
    "a": [
        {
            "i": "EBXOxFQrvOxBPb7DiRaTlZNLvX5RbL5cO05MdA35Z0vl",
            "s": "0",
            "d": "EBXOxFQrvOxBPb7DiRaTlZNLvX5RbL5cO05MdA35Z0vl"
        }
    ]
}
{
    "v": "KERI10JSON00013a_",
    "t": "ixn",
    "d": "EGZKcIKf9euYtsGJI5RxWoL6sprJS8Rt6Em97X85tJPq",
    "i": "EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
    "s": "2",
    "p": "EMllQ2kDZp9OnErTfJkzqbZN4hoH-rATBvVyASczJFIN",
    "a": [
        {
            "i": "EA7VoZA6B9hmhmJAuWUU4lNxRBIQ3sv6JZXGeLnJCRGZ",
            "s": "0",
            "d": "EBCVtYB15CiJg79EciGiAkQaU3L-4oCx7qcPqUsQGZqr"
        }
    ]
}
{
    "v": "KERI10JSON000109_",
    "t": "rpy",
    "d": "EAVexvYonCqxXNNQ8208SLo3Afcg9W7d7eiNJ2FC8tMe",
    "dt": "2025-04-16T16:50:26.283032-07:00",
    "r": "/loc/scheme",
    "a": {
        "eid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q",
        "scheme": "https",
        "url": "https://wit1.did-webs-service:5641/"
    }
}
{
    "v": "KERI10JSON000105_",
    "t": "rpy",
    "d": "ENAFmV935lXzYQfDKwgjU08o-AC5ZfqhGR2dtgka1kvq",
    "dt": "2025-04-16T16:50:26.283032-07:00",
    "r": "/loc/scheme",
    "a": {
        "eid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q",
        "scheme": "tcp",
        "url": "tcp://wit1.did-webs-service:5631/"
    }
}
{
    "v": "KERI10JSON000116_",
    "t": "rpy",
    "d": "EIUHDBQmdOf7B0TwHqREnB-_gGYa2b9exOcLJMylrp6P",
    "dt": "2025-04-16T16:50:26.283032-07:00",
    "r": "/end/role/add",
    "a": {
        "cid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q",
        "role": "controller",
        "eid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q"
    }
}
// issuance of designated alias ACDC authorizing host information for did:webs and did:web
{
    "v": "KERI10JSON0000ff_",
    "t": "vcp",
    "d": "EBXOxFQrvOxBPb7DiRaTlZNLvX5RbL5cO05MdA35Z0vl",
    "i": "EBXOxFQrvOxBPb7DiRaTlZNLvX5RbL5cO05MdA35Z0vl",
    "ii": "EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
    "s": "0",
    "c": [
     "NB"
    ],
    "bt": "0",
    "b": [],
    "n": "0AAuhv_GQrchdHyeZGXUMFw1"
}
{
    "v": "KERI10JSON0000ed_",
    "t": "iss",
    "d": "EBCVtYB15CiJg79EciGiAkQaU3L-4oCx7qcPqUsQGZqr",
    "i": "EA7VoZA6B9hmhmJAuWUU4lNxRBIQ3sv6JZXGeLnJCRGZ",
    "s": "0",
    "ri": "EBXOxFQrvOxBPb7DiRaTlZNLvX5RbL5cO05MdA35Z0vl",
    "dt": "2026-02-06T21:44:36.788115+00:00"
}
{
    "v": "ACDC10JSON000574_",
    "d": "EA7VoZA6B9hmhmJAuWUU4lNxRBIQ3sv6JZXGeLnJCRGZ",
    "i": "EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
    "ri": "EBXOxFQrvOxBPb7DiRaTlZNLvX5RbL5cO05MdA35Z0vl",
    "s": "EN6Oh5XSD5_q2Hgu-aqpdfbVepdpYpFlgz6zvJL5b_r5",
    "a": {
        "d": "ELt92UqnBvlk8UOWpK2uUWlXEohe6j_JEVP4zvRY3HB-",
        "dt": "2026-02-06T21:44:36.788115+00:00",
        "ids": [
            "did:web:did-webs-service%3a7702:EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
            "did:webs:did-webs-service%3a7702:EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP"
        ]
    },
    "r": {
    "d": "EEVTx0jLLZDQq8a5bXrXgVP0JDP7j8iDym9Avfo8luLw",
    "aliasDesignation": {
      "l": "The issuer of this ACDC designates the identifiers in the ids field as the only allowed namespaced aliases of the issuer's AID."
    },
    "usageDisclaimer": {
      "l": "This attestation only asserts designated aliases of the controller of the AID, that the AID controlled namespaced alias has been designated by the controller. It does not assert that the controller of this AID has control over the infrastructure or anything else related to the namespace other than the included AID."
    },
    "issuanceDisclaimer": {
      "l": "All information in a valid and non-revoked alias designation assertion is accurate as of the date specified."
    },
    "termsOfUse": {
      "l": "Designated aliases of the AID must only be used in a manner consistent with the expressed intent of the AID controller."
    }
    }
}

{
  "id": "did:webs:did-webs-service%3a7702:EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
  "controller": "did:webs:did-webs-service%3a7702:EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
  "verificationMethod": [
    {
      "id": "#DJg7AQUSKAEo-Pkgj4tVF7L0-FqJt0QFxFh5878AcZv6",
      "type": "JsonWebKey",
      "controller": "did:webs:did-webs-service%3a7702:EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
      "publicKeyJwk": {
        "kid": "DJg7AQUSKAEo-Pkgj4tVF7L0-FqJt0QFxFh5878AcZv6",
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "mDsBBRIoASj4-SCPi1UXsvT4Wom3RAXEWHnzvwBxm_o"
      }
    }
  ],
  "authentication": [
    "#DJg7AQUSKAEo-Pkgj4tVF7L0-FqJt0QFxFh5878AcZv6"
  ],
  "assertionMethod": [
    "#DJg7AQUSKAEo-Pkgj4tVF7L0-FqJt0QFxFh5878AcZv6"
  ],
  "service": [
    {
      "id": "#BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q/witness",
      "type": "witness",
      "serviceEndpoint": {
        "https": "https://wit1.did-webs-service:5641/",
        "tcp": "tcp://wit1.did-webs-service:5631/"
      }
    }
  ],
  "alsoKnownAs": [
    "did:web:did-webs-service%3a7702:EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP",
    "did:keri:EEOqE46OOSl1k1JO3ggQTGuQR3nnWE8bYjOPnJ53m8CP"
  ]
}

§ Basic KERI event details

This section is normative.

DID documents introduced the core KERI event stream and related DID document concepts. This section provides additional details regarding the basic types of KERI events and how they relate to the DID document.

§ Key state events

1. When processing the KERI event stream did:webs MUST account for two broad types of key state events (KERI parlance is ‘establishment events’) that can alter the key state of the AID.
2. Any change in key state of the AID MUST be reflected in the DID document.
3. If a key state event does not commit to a future set of rotation key hashes, then the AID SHALL NOT be rotated to new keys in the future (KERI parlance is that the key state of the AID becomes ‘non-transferable’).
4. If a key state event does commit to a future set of rotation key hashes, then any future key state rotation MUST be to those commitment keys. This foundation of pre-rotation is post-quantum safe and allows the did:webs controller to recover from key compromise.
5. The Inception event MUST be the first event in the KEL that establishes the AID.
   1. This MUST define the initial key set
   2. If the controller(s) desire future key rotation (transfer) then the inception event MUST commit to a set of future rotation key hashes.
   3. When processing the KERI event stream, if there are no rotation events after the inception event, then this is the current key state of the AID and MUST be reflected in the DID document as specified in Verification Methods and Verification Relationships.
6. Rotation events MUST come after inception events.
7. If the controller(s) desires future key rotation (transfer) then the rotation event MUST commit to a set of future rotation key hashes.
8. Rotation events MUST only change the key state to the previously committed to rotation keys.
9. Either the inception event or the last rotation event, if any, is the current key state of the AID and MUST be reflected in the DID document as specified in Verification Methods and Verification Relationships.

§ Delegation KERI event details

This section focuses on delegation relationships between KERI AIDs. DID documents introduced the core KERI event stream and related DID document concepts. This section provides additional details regarding the types of KERI delegation events and how they relate to the DID document. See Basic KERI event details for further detail on basic KERI event types including how they relate to the DID document.

§ Delegation key state events

1. All delegation relationships MUST start with a delegated inception event.
2. Any change to the delegated inception event key state or delegated rotation event key state MUST be the result of a delegated rotation event.

Delegation service endpoints in the DID document are defined in the next section.

§ Service Endpoint Event Details

This section is normative.

In did:webs, KERI-derived service endpoints are defined by Location Scheme (/loc/scheme) reply (rpy) messages and, for roles other than witness, Endpoint Role Authorization (/end/role/add) rpy messages in the KERI event stream. Location Scheme records declare URL(s) for a given scheme for an AID; Endpoint Role Authorization relates a role (e.g. mailbox, agent) of one AID to another. See KERI Service Endpoints as DID document metadata.

When the event stream (or equivalent key state and endpoint data) for a did:webs DID establishes a witness, mailbox, or agent the DID document MUST include the associated service endpoint(s) in its service array.

§ Witness Service Endpoint

1. A witness service endpoint is produced when (1) the controller AID’s KEL designates the witness in its witness list (inception or latest rotation event b field), and (2) one or more Location Scheme rpy messages with r /loc/scheme declare URLs for that witness AID (a.eid) per scheme. The witness role is thus established by key state, not by an Endpoint Role Authorization rpy.
2. The DID document service entry SHALL use type witness, id relative to the DID of the form #<witness-aid>/witness, and serviceEndpoint as an object whose keys are scheme names and values are the declared URLs.

Location Scheme examples (witness AID declares https and tcp URLs):

{
  // ...
  "t": "rpy",
  "r": "/loc/scheme",
  "a": {
    "eid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q",
    "scheme": "https",
    "url": "https://wit1.example.com:5641/"
  }
}

{
  // ...
  "t": "rpy",
  "r": "/loc/scheme",
  "a": {
    "eid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q",
    "scheme": "tcp",
    "url": "tcp://wit1.example.com:5631/"
  }
}

Resulting witness service entry:

{
  "id": "#BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q/witness",
  "type": "witness",
  "serviceEndpoint": {
    "https": "https://wit1.example.com:5641/",
    "tcp": "tcp://wit1.example.com:5631/"
  }
}

§ Mailbox Service Endpoint

1. A mailbox service endpoint is produced when (1) an Endpoint Role Authorization rpy with r /end/role/add and a.role mailbox designates the mailbox AID (a.eid) for the controller AID (a.cid), and (2) one or more Location Scheme rpy messages with r /loc/scheme declare URLs for that mailbox AID. Implementations obtain mailbox endpoints from Endpoint Role data (e.g. KERI ends table keyed by controller and role) plus Location Scheme data (e.g. locs table).
2. The DID document service entry SHALL use type mailbox, id relative to the DID of the form #<mailbox-aid>/mailbox, and serviceEndpoint as an object mapping scheme names to URLs (or a single URL when only one scheme applies).

Endpoint Role Authorization example (controller designates mailbox):

{
  // ...
  "t": "rpy",
  "r": "/end/role/add",
  "a": {
    "cid": "Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
    "role": "mailbox",
    "eid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q"
  }
}

Location Scheme example (mailbox AID declares http URL):

{
  // ...
  "t": "rpy",
  "r": "/loc/scheme",
  "a": {
    "eid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q",
    "scheme": "http",
    "url": "http://mailbox.example.com:5635/"
  }
}

Resulting mailbox service entry:

{
  "id": "#BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q/mailbox",
  "type": "mailbox",
  "serviceEndpoint": {
    "http": "http://mailbox.example.com:5635/"
  }
}

§ Delegator Service Endpoint

If the first event in the KEL for a did:webs DID is a delegated inception event of type dip then it MUST include a delegator service endpoint in its DID document as follows.

1. A delegated AID MUST include a service endpoint in its DID document that references its delegator.
2. When a delegator service endpoint is present, it MUST conform to the following requirements:
   1. The service type property MUST be set to DelegatorOOBI.
   2. The service id property MUST be the self-addressing identifier (SAID) of the seal (anchor block) in the delegator’s KEL that commits to the delegate’s delegated inception event.
   3. The service serviceEndpoint property MUST be a valid out-of-band introduction (OOBI) URL that resolves to the delegator’s AID.
3. The delegator service endpoint only indicates where the delegator’s KERI state may be retrieved. Its presence MUST NOT be treated as proof or validation of the delegation relationship. A KERI-aware verifier validates the relationship independently by retrieving the delegator’s KEL and verifying the source seal that authorizes the delegated event.

For example, a did:webs DID that is a delegated AID MUST include, in its service array of the DID document, a delegator service endpoint similar to the following:

{
  "service": [{
    "id": "EDEvmKvGFjuip-J5dDw7sbVHxXA22s-pBO764CivsFt4",
    "type": "DelegatorOOBI",
    "serviceEndpoint": "http://example.com:3902/oobi/ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
  }]
}

§ Agent Service Endpoint

1. An agent service endpoint is produced when (1) an Endpoint Role Authorization rpy with r /end/role/add and a.role agent designates the agent AID (a.eid) for the controller AID (a.cid), and (2) one or more Location Scheme rpy messages with r /loc/scheme declare URLs for that agent AID. Implementations obtain agent endpoints from Endpoint Role data (e.g. KERI ends table) plus Location Scheme data (e.g. locs table).
2. The DID document service entry SHALL use type agent and serviceEndpoint as an object mapping scheme names to URLs or a single URL, consistent with KERI Service Endpoints as DID document metadata.

Endpoint Role Authorization example (controller designates agent):

{
  // ...
  "t": "rpy",
  "r": "/end/role/add",
  "a": {
    "cid": "Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
    "role": "agent",
    "eid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q"
  }
}

Location Scheme example (agent AID declares http URL):

{
  // ...
  "t": "rpy",
  "r": "/loc/scheme",
  "a": {
    "eid": "BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q",
    "scheme": "http",
    "url": "http://agent.example.com:5636/"
  }
}

Resulting agent service entry:

{
  "id": "#BJqHtDoLT_K_XyOgr2ejBOqD9276TYMTg2EEqWKs-V0q/agent",
  "type": "agent",
  "serviceEndpoint": {
    "http": "http://agent.example.com:5636/"
  }
}

§ Designated Aliases

1. An AID controller SHALL authorize designated aliases by issuing a Designated aliases verifiable attestation as an ACDC.
   1. This attestation MUST contain a set of AID controlled identifiers that the AID controller authorizes.
   2. Authorized identifiers MUST be reflected in the DID document and DID document metadata according to the following rules:

§ Designated Aliases event details

{
  "v": "ACDC10JSON000574_",
  "d": "EA7VoZA6B9hmhmJAuWUU4lNxRBIQ3sv6JZXGeLnJCRGZ",
  "i": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
  "ri": "EBXOxFQrvOxBPb7DiRaTlZNLvX5RbL5cO05MdA35Z0vl",
  "s": "EN6Oh5XSD5_q2Hgu-aqpdfbVepdpYpFlgz6zvJL5b_r5",
  "a": {
    "d": "ELt92UqnBvlk8UOWpK2uUWlXEohe6j_JEVP4zvRY3HB-",
    "dt": "2026-02-06T21:44:36.788115+00:00",
    "ids": [
      "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
      "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
      "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
      "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
      "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
    ]
  },
  "r": {
    ...rules section
  }
}

{
    "didDocument": {
        "id": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
        "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
        "verificationMethod": [
            {
                "id": "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
                "type": "JsonWebKey",
                "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
                "publicKeyJwk": {
                    "kid": "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
                    "kty": "OKP",
                    "crv": "Ed25519",
                    "x": "evT4j6Yw3uHpwsw5NEmSR8-4x3S-BA-s6Thjd51oeOs"
                }
            }
        ],
        "authentication": [
          "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
        ],
        "assertionMethod": [
          "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
        ],
        "service": [],
        "alsoKnownAs": [
            "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:keri:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
        ]
    },
    "didResolutionMetadata": {
        "contentType": "application/did+json",
        "retrieved": "2024-04-01T17:43:24Z"
    },
    "didDocumentMetadata": {
        "witnesses": [],
        "versionId": "2",
        "equivalentId": [
            "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
        ],
        "didDocUrl": "http://did-webs-service:7676/ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe/did.json",
        "keriCesrUrl": "http://did-webs-service:7676/ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe/keri.cesr"
    }
}

§ DID Parameters

This section is normative.

This section describes the support of the did:webs method for certain DID parameters.

§ Support for versionId

The did:webs DID method supports the versionId DID parameter. This DID parameter is defined in the DID specification.

This allows clients to instruct a DID Resolver to return a specific version of a DID document, as opposed to the latest version. The did:webs DID method is ideally suited for this functionality, since a continuous, self-certifying stream of events lies at the heart of the DID method’s design, see section KERI Fundamentals.

1. Valid values for this DID parameter MUST be the sequence numbers of events in the KERI event stream.
2. When a did:webs DID is resolved with this DID parameter, a did:webs resolver MUST construct the DID document based on an AID’s associated KERI events from the KERI event stream only up to (and including) the event with the sequence number (i.e. the s field) that corresponds to the value of the versionId DID parameter.

did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M?versionId=1

§ Support for transformKeys

The did:webs DID method supports the transformKeys DID parameter. This DID parameter is defined as a DID method extension.

1. This parameter MUST be implemented for a DID Resolver to return verification methods in a DID document in a desired format, such as JsonWebKey, Ed25519VerificationKey2020, or CesrKey.

did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M?transformKeys=CesrKey

§ CesrKey and publicKeyCesr

This specification defines the following DID document extensions:

1. Verification method type CesrKey MAY be available in a did:webs DID document to express a public key encoded in CESR format.
2. Verification method property publicKeyCesr MAY be available in a did:webs DID document to provide a string value whose content is the CESR representation of a public key.
3. The verification method type CesrKey MAY be used as the value of the transformKeys DID parameter.

{
  "v": "KERI10JSON0001b7_",
  "t": "icp",
  "d": "Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "i": "Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "s": "0",
  "kt": "1",
  "k": [
    "1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",  // Secp256k1 Key
    "DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",      // Ed25519 Key
    "DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu"       // Ed25519 Key
  ],
  // ...
}

did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M?transformKeys=CesrKey

{
  "verificationMethod": [
    {
      "id": "#1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk",
      "type": "CesrKey",
      "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
      "publicKeyCesr": "1AAAAg299p5IMvuw71HW_TlbzGq5cVOQ7bRbeDuhheF-DPYk"
    },
    {
      "id": "#DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE",
      "type": "CesrKey",
      "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
      "publicKeyCesr": "DA-vW9ynSkvOWv5e7idtikLANdS6pGO2IHJy7v0rypvE"
    },
    {
      "id": "#DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu",
      "type": "CesrKey",
      "controller": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
      "publicKeyCesr": "DLWJrsKIHrrn1Q1jy2oEi8Bmv6aEcwuyIqgngVf2nNwu"
    }
  ]
}

§ DID Metadata

This section is normative.

This section describes the support of the did:webs method for metadata, including DID resolution metadata and DID document metadata. This metadata is returned by a DID Resolver in addition to the DID document. Also see the DID Resolution specification for further details.

§ DID Resolution Metadata

At the moment, this specification does not define the use of any specific DID resolution metadata properties in the did:webs method, but may in the future include various metadata, such as which KERI Watchers were used during the resolution process.

§ DID document metadata

This section of the specification defines how various DID document metadata properties are used by the did:webs method.

§ Use of versionId

The versionId DID document metadata property indicates the current version of the DID document that has been resolved.

1. The did:webs versionId MUST be the sequence number (i.e. the s field) of the last event in the KERI event stream that was used to construct the DID document according to the rules in section DID documents.
2. If the DID parameter versionId (see section Support for versionId) was used when resolving the did:webs DID, and if the DID Resolution process was successful, then this corresponding DID document metadata property MUST be guaranteed to be equal to the value of the DID parameter.

Example:

{
  "didDocument": {
    "id": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M"
    // ... other properties
  },
  "didResolutionMetadata": {
  },
  "didDocumentMetadata": {
    "versionId": "2"
  }
}

§ Use of nextVersionId

The nextVersionId DID document metadata property indicates the next version of the DID document after the version that has been resolved.

1. The did:webs nextVersionId MUST be the sequence number (i.e. the s field) of the next event in the KERI event stream after the last one that was used to construct the DID document according to the rules in section DID documents.
2. This DID document metadata property MUST be present if the DID parameter versionId (see section Support for versionId) was used when resolving the did:webs DID, and if the value of that DID parameter was not the sequence number of the last event in the KERI event stream.

Example:

{
  "didDocument": {
    "id": "did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M"
    // ... other properties
  },
  "didResolutionMetadata": {
  },
  "didDocumentMetadata": {
    "versionId": "1",
    "nextVersionId": "2"
  }
}

§ Use of equivalentId

The equivalentId DID document metadata property indicates other DIDs that refer to the same subject and are logically equivalent to the DID that has been resolved. It is similar to the alsoKnownAs DID document property (see section Also Known As), but it has even stronger semantics, insofar as the logical equivalence is guaranteed by the DID method itself.

1. A did:webs DID MUST NOT successfully resolve unless the resolved DID appears in a valid, unrevoked designated aliases ACDC in the KERI event stream.
2. The did:webs equivalentId metadata property SHOULD contain the other designated aliases that are did:webs DIDs sharing the same AID but differing in the host, port, and/or path portion of the method-specific identifier. Also see section AID controlled identifiers and Designated Aliases.
3. The resolved DID itself MUST NOT be required to appear in equivalentId; equivalentId lists other authorized same-AID did:webs DIDs.

Note that AID controlled identifiers like did:web and did:keri identifiers with the same AID are not listed in equivalentId because they do not have the same DID method. A did:web identifier with the same domain and AID does not have the same security characteristics as the did:webs identifier. Conversely, a did:keri identifier with the same AID has the same security characteristics but not the same dependence on the web. For these reasons, they are not listed in equivalentId.

Example:

{
    "didDocument": {
        "id": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
        "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
        "verificationMethod": [
            {
                "id": "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
                "type": "JsonWebKey",
                "controller": "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
                "publicKeyJwk": {
                    "kid": "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr",
                    "kty": "OKP",
                    "crv": "Ed25519",
                    "x": "evT4j6Yw3uHpwsw5NEmSR8-4x3S-BA-s6Thjd51oeOs"
                }
            }
        ],
        "authentication": [
          "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
        ],
        "assertionMethod": [
          "#DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
        ],
        "service": [],
        "alsoKnownAs": [
            "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:keri:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
        ]
    },
    "didResolutionMetadata": {
        "contentType": "application/did+json",
        "retrieved": "2024-04-01T17:43:24Z"
    },
    "didDocumentMetadata": {
        "witnesses": [],
        "versionId": "2",
        "equivalentId": [
            "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
        ],
        "didDocUrl": "http://did-webs-service:7676/ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe/did.json",
        "keriCesrUrl": "http://did-webs-service:7676/ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe/keri.cesr"
    }
}

§ Security Considerations

This section is normative.

The security of did:webs separates discovery (finding did.json and keri.cesr on the web) from authenticity (cryptographically verifying the KERI event stream and deriving the DID document). Authenticity of a resolved did:webs DID document MUST NOT depend on host honesty. A conforming resolver MUST establish authenticity by verifying the KERI event stream and applying the rules in Read (Resolve) and DID documents.

§ Common security threats

The following maps common threats to the mechanisms this method uses. MUST requirements below are limited to behaviors already required elsewhere in this specification; optional KERI infrastructure is expressed with SHOULD.

1. Forgery, malleability, and impersonation of DID document content. A resolver MUST accept a DID document only when it is derived from a verified KERI event stream and equals the transformed hosted did.json, per Read (Resolve). Hosted JSON alone MUST NOT be trusted.
2. Unauthorized host or path aliases. A resolver MUST NOT treat a did:webs or corresponding did:web identifier as authorized unless it appears in a valid, unrevoked designated aliases ACDC, per Designated Aliases.
3. Key compromise. Controllers SHOULD use KERI pre-rotation and key rotation so that compromise of current signing keys does not allow an attacker to permanently seize the AID. See Key state events.
4. Duplicity and eclipse. Controllers and resolvers SHOULD use KERI witnesses and watchers to detect forked or inconsistently published event streams, per AID controlled identifiers.
5. Deletion or withholding of history. A single host MAY omit, delay, or serve stale copies of did.json or keri.cesr. Controllers MUST continue to publish deactivated artifacts per Deactivate. Resolvers MAY discover alternate locations via designated aliases, equivalentId, or other AID-based discovery; the method does not by itself guarantee availability.
6. Replay. KERI event verification and, where used, KRAM constrain replay of signed protocol messages. Resolvers MUST apply KERI verification rules to the event stream; additional replay protections for discovery traffic SHOULD follow the KEL / BADA-RUN / KRAM guidance in Concepts for securing did:webs information.
7. Denial of service and BOLA. Availability of hosts and authorization bugs in surrounding applications are largely outside the scope of this DID method. Hosting SHOULD follow accepted operational practice. The method’s authenticity guarantees remain those of KERI verification even when a host is unavailable or untrustworthy.

§ Using HTTPS

HTTPS protects the confidentiality and integrity of the transport used to fetch did.json and keri.cesr. It does not, by itself, establish the authenticity of a did:webs DID document. Perfect protection from eavesdropping is not always possible with HTTPS.

1. URLs of DID documents and KERI event streams SHOULD be hosted according to accepted cybersecurity practice for public HTTPS resources (for example, rate limiting and monitoring appropriate to the deployment).
2. A host that uses a fully qualified domain name of the method-specific identifier MUST be secured by a TLS/SSL certificate.
   1. The fully qualified domain name MUST match the common name (or an appropriate subject alternative name) used in the SSL/TLS certificate.
   2. The name in the SSL/TLS certificate from the server MUST correspond to the way the server is referenced in the URL. For example, if the URL includes www.example.com, the certificate MUST cover www.example.com as well.
3. Unlike did:web, the URL MAY use an IP address instead.
   1. If it does, then the certificate MUST identify that IP address (for example via common name or subject alternative name).
4. The URL and the certificate MUST NOT identify the server in contradictory ways; subject to that constraint, how the server is identified is flexible.
   1. The server certificate MAY be self-issued
   2. OR it MAY chain back to an unknown certificate authority. However, it MUST be valid for the client to accept it for the HTTPS session:
      1. The certificate MUST satisfy the client’s active trust requirements such that the client accepts it and uses it to establish the encrypted session.
      2. Even if the client is permissive about certificate authorities, the certificate MUST have a valid signature, MUST NOT be expired, revoked, or deny-listed, and MUST NOT have broken links in its chain of trust.
5. If a URL of a DID document or KERI event stream results in a redirect, each URL in the redirect chain MUST satisfy the same security requirements.

§ International Domain Names

1. As with did:web, implementers of did:webs SHOULD consider how non-ASCII characters manifest in URLs and DIDs.
   1. did:webs MUST follow the DID Core identifier syntax which does not allow the direct representation of such characters in method name or method specific identifiers. This prevents a did:webs value from embodying a homograph attack.
   2. However, did:webs MAY hold data encoded with punycode or percent encoding. This means that IRIs constructed from DID values could contain non-ASCII characters that were not obvious in the DID, surprising a casual human reader.
   3. Caution is RECOMMENDED when treating a did:webs as the equivalent of an IRI.
   4. Treating it as the equivalent of a URL, instead, is RECOMMENDED as it preserves the punycode and percent encoding and is therefore safe.

§ Concepts for securing did:webs information

The following security concepts are used to secure the data, files, signatures and other information in did:webs.

1. All security features and concepts in did:webs MUST use one or more of the following mechanisms:
   1. All data that requires the highest security MUST be KEL backed. This includes any information that needs to be end-verifiably authentic over time:
      1. All ACDCs used by a did:webs identifier MUST be one of the following:
         1. MAY be anchored to a KEL directly.
         2. MAY be anchored indirectly through a TEL that itself is anchored to a KEL.
   2. All data that does not need to incur the cost of KEL backing for security but can benefit from the latest data-state such as a distributed data-base MUST use Best Available Data - Read, Update, Nullify (BADA-RUN).
      1. BADA-RUN information MUST be ordered in a consistent way, using the following:
         1. date-time MUST be used.
         2. key state MUST be used.
      2. Discovery information MAY use BADA-RUN because the worst-case attack on discovery information is a DDoS attack where nothing gets discovered.
         1. The controller(s) of the AID for a did:webs identifier MAY use BADA-RUN for service end-points as discovery mechanisms.
   3. All data that does not need the security of being KEL backed nor BADA-RUN SHOULD be served using KERI Request Authentication Mechanism (KRAM).
      1. For a did:webs resolver to be trusted it SHOULD use KRAM to access the service endpoints providing KERI event streams for verification of the DID document.

§ Reducing the attack surface

§ Privacy Considerations

§ IANA Considerations

This section is normative.

KERI event streams use the registered application/cesr media type with IANA. The media type is application/cesr. The registration follows the template in RFC6838.

§ Implementors Guide

These sections are informative.

§ Key Agreement

§ Other Key Commitments

§ On-Disk Storage

§ Alignment of Information to Security Posture

§ Applying the concepts of KEL, BADA-RUN, and KRAM to did:webs

§ The set of KERI features needed

§ Stable identifiers on an unstable web

§ KERI event stream chain of custody

§ Verifiable data on a TEL

{
    "v": "ACDC10JSON0005f2_",
    "d": "EIGWggWL2IHiUzj1P2YuPA0-Uh55LTIu14KTvVQGrfvT",
    "i": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "ri": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
    "s": "EN6Oh5XSD5_q2Hgu-aqpdfbVepdpYpFlgz6zvJL5b_r5",
    "a": {
        "d": "EJJjtYa6D4LWe_fqtm1p78wz-8jNAzNX6aPDkrQcz27Q",
        "dt": "2023-11-13T17:41:37.710691+00:00",
        "ids": [
            "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
        ]
    },
    "r": {
        "d": "EEVTx0jLLZDQq8a5bXrXgVP0JDP7j8iDym9Avfo8luLw",
        "aliasDesignation": {
            "l": "The issuer of this ACDC designates the identifiers in the ids field as the only allowed namespaced aliases of the issuer's AID."
        },
        "usageDisclaimer": {
            "l": "This attestation only asserts designated aliases of the controller of the AID, that the AID controlled namespaced alias has been designated by the controller. It does not assert that the controller of this AID has control over the infrastructure or anything else related to the namespace other than the included AID."
        },
        "issuanceDisclaimer": {
            "l": "All information in a valid and non-revoked alias designation assertion is accurate as of the date specified."
        },
        "termsOfUse": {
            "l": "Designated aliases of the AID must only be used in a manner consistent with the expressed intent of the AID controller."
        }
    }
}

§ The interaction event on the KEL

    "v": "KERI10JSON00013a_",
    "t": "ixn",
    "d": "ED-4iQIVxwMcrTOW6fVs9oPpLTIxtqh_vcvLmE999zsU",
    "i": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "s": "1",
    "p": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "a": [
        {
            "i": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
            "s": "0",
            "d": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx"
        }
    ]

§ The TEL registry

    "v": "KERI10JSON000113_",
    "t": "vcp",
    "d": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
    "i": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
    "ii": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "s": "0",
    "c": [
        "NB"
    ],
    "bt": "0",
    "b": [],
    "n": "AAfqHwMDdBoIWk_4Z6hvVJuhtvjA_gk8Y9bEUoP_rC_p"

§ The attestation status

    "v": "KERI10JSON0000ed_",
    "t": "iss",
    "d": "EJQvCZQYn8oO1z3_f8qhxXjk7TcLol4G3RdHVTwfGV3L",
    "i": "EIGWggWL2IHiUzj1P2YuPA0-Uh55LTIu14KTvVQGrfvT",
    "s": "0",
    "ri": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
    "dt": "2023-11-13T17:41:37.710691+00:00"

§ The full KERI event stream

{
    "v": "KERI10JSON00012b_",
    "t": "icp",
    "d": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "i": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "s": "0",
    "kt": "1",
    "k": [
        "DHr0-I-mMN7h6cLMOTRJkkfPuMd0vgQPrOk4Y3edaHjr"
    ],
    "nt": "1",
    "n": [
        "ELa775aLyane1vdiJEuexP8zrueiIoG995pZPGJiBzGX"
    ],
    "bt": "0",
    "b": [],
    "c": [],
    "a": []
}-VAn-AABAADjfOjbPu9OWce59OQIc-y3Su4kvfC2BAd_e_NLHbXcOK8-3s6do5vBfrxQ1kDyvFGCPMcSl620dLMZ4QDYlvME-EAB0AAAAAAAAAAAAAAAAAAAAAAA1AAG2024-04-01T17c40c48d329209p00c00{
    "v": "KERI10JSON00013a_",
    "t": "ixn",
    "d": "ED-4iQIVxwMcrTOW6fVs9oPpLTIxtqh_vcvLmE999zsU",
    "i": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "s": "1",
    "p": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "a": [
        {
            "i": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
            "s": "0",
            "d": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx"
        }
    ]
}-VAn-AABAACNra5mDg7YHFtBeXiwIGqnHkyq7F55FGNYG1wH95akjSWCb1HzNI3E05ufT0HffClDxnJF_DmAUW2SBb0EJeoO-EAB0AAAAAAAAAAAAAAAAAAAAAAB1AAG2024-04-01T17c42c37d704426p00c00{
    "v": "KERI10JSON00013a_",
    "t": "ixn",
    "d": "EBjw0a_L8M0F4xYND99dvahlrkpxODi9Wc9VzUvkhD0t",
    "i": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "s": "2",
    "p": "ED-4iQIVxwMcrTOW6fVs9oPpLTIxtqh_vcvLmE999zsU",
    "a": [
        {
            "i": "EIGWggWL2IHiUzj1P2YuPA0-Uh55LTIu14KTvVQGrfvT",
            "s": "0",
            "d": "EJQvCZQYn8oO1z3_f8qhxXjk7TcLol4G3RdHVTwfGV3L"
        }
    ]
}-VAn-AABAABo_okwAmWIYWI93EtUONZiEvsGuSRkKnj0mopX_RoXwWHZ_1V5hQ0BxcntsmAi21DbusyCmK-fHwTNtSxUSsoN-EAB0AAAAAAAAAAAAAAAAAAAAAAC1AAG2024-04-01T17c42c39d995867p00c00{
    "v": "KERI10JSON000113_",
    "t": "vcp",
    "d": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
    "i": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
    "ii": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "s": "0",
    "c": [
        "NB"
    ],
    "bt": "0",
    "b": [],
    "n": "AAfqHwMDdBoIWk_4Z6hvVJuhtvjA_gk8Y9bEUoP_rC_p"
}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAABED-4iQIVxwMcrTOW6fVs9oPpLTIxtqh_vcvLmE999zsU{
    "v": "KERI10JSON0000ed_",
    "t": "iss",
    "d": "EJQvCZQYn8oO1z3_f8qhxXjk7TcLol4G3RdHVTwfGV3L",
    "i": "EIGWggWL2IHiUzj1P2YuPA0-Uh55LTIu14KTvVQGrfvT",
    "s": "0",
    "ri": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
    "dt": "2023-11-13T17:41:37.710691+00:00"
}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAACEBjw0a_L8M0F4xYND99dvahlrkpxODi9Wc9VzUvkhD0t{
    "v": "ACDC10JSON0005f2_",
    "d": "EIGWggWL2IHiUzj1P2YuPA0-Uh55LTIu14KTvVQGrfvT",
    "i": "ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
    "ri": "EAtQJEQMkkvlWxyfLbcLyv4kNeAI5Qsqe65vKIWnHKpx",
    "s": "EN6Oh5XSD5_q2Hgu-aqpdfbVepdpYpFlgz6zvJL5b_r5",
    "a": {
        "d": "EJJjtYa6D4LWe_fqtm1p78wz-8jNAzNX6aPDkrQcz27Q",
        "dt": "2023-11-13T17:41:37.710691+00:00",
        "ids": [
            "did:web:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:webs:did-webs-service%3a7676:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:web:example.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:web:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe",
            "did:webs:foo.com:ENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe"
        ]
    },
    "r": {
        "d": "EEVTx0jLLZDQq8a5bXrXgVP0JDP7j8iDym9Avfo8luLw",
        "aliasDesignation": {
            "l": "The issuer of this ACDC designates the identifiers in the ids field as the only allowed namespaced aliases of the issuer's AID."
        },
        "usageDisclaimer": {
            "l": "This attestation only asserts designated aliases of the controller of the AID, that the AID controlled namespaced alias has been designated by the controller. It does not assert that the controller of this AID has control over the infrastructure or anything else related to the namespace other than the included AID."
        },
        "issuanceDisclaimer": {
            "l": "All information in a valid and non-revoked alias designation assertion is accurate as of the date specified."
        },
        "termsOfUse": {
            "l": "Designated aliases of the AID must only be used in a manner consistent with the expressed intent of the AID controller."
        }
    }
}-VA0-FABENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe0AAAAAAAAAAAAAAAAAAAAAAAENro7uf0ePmiK3jdTo2YCdXLqW7z7xoP6qhhBou6gBLe-AABAADQOX208DAmZEPb2v0XXF0N6WgxOdOxB3AsCBJds_vbAr7v1PQBA4MWNsXc8unk5UykbB8j538XGkzLtujekvIP

§ Adding service endpoint roles in KERI

{
  "service": [
      {
        "id":"#Bgoq68HCmYNUDgOz4Skvlu306o_NY-NrYuKAVhk3Zh9c",
        "type": "DIDCommMessaging", 
        "serviceEndpoint": "https://bar.example.com"
      },
      {
        "id":"#BuyRFMideczFZoapylLIyCjSdhtqVb31wZkRKvPfNqkw",
        "type": "agent", 
        "serviceEndpoint": {
          "tcp": "tcp://bar.example.com:5542",
          "https": "https://bar.example.com" 
        }
      }
  ]
}

§ Annex

§ KERI Fundamentals

§ Bibliography

§ Normative section

. W3C, Data Integrity Proofs.

. IETF, RFC 7515 Section 3.2: JWS JSON Serialization.

. Multiformats, multihash.

. IETF, RFC 1035: Domain Names - Implementation and Specification.

. IETF, RFC 1123: Requirements for Internet Hosts - Application and Support.

. IETF, RFC 2181: Clarifications to the DNS Specification.

. IETF, RFC 3986: Uniform Resource Identifier (URI): Generic Syntax.

§ Trust-over-IP

. Trust over IP, Authentic Chained Data Containers (ACDC) specification.

. Trust over IP, Composable Event Streaming Representation (CESR).

. Trust over IP, CESR Proof Signatures specification.

. Trust over IP, Key Event Receipt Infrastructure (KERI) specification.

. Trust over IP, ACDC IPEX validation.

§ W3C

. W3C CCG, did:web Method Specification.

. W3C, Decentralized Identifiers (DIDs) v1.0.

. W3C, DID Spec Registries.

. W3C, DID URL path.

. W3C, Verifiable Credentials Data Model.

. W3C, Verifiable Presentations.

§ Informative section