Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduction of the three approaches #6

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Introduction of the three approaches #6

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 22 additions & 15 deletions draft-pfeairheller-did-keri.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -212,17 +212,36 @@ A self-addressing, self-certifying identifier is cryptographically bound to the
did:keri:EXq5YqaL6L48pf0fu7IUhL0JRaU2\_RxFP0AL43wYn148


# Operations
# DID Operations

The following section outlines the DID operations for the did:keri method.

## Create
## Create DID

Creation of a did:keri DID is accomplished by creating, signing and publishing an Inception event. If witnesses are listed in the inception event, the receipts are also required for DID creation to be complete.

Detailed steps for prefix derivation are in \[\[KID0001\]\] and witness configuration in \[\[KID0009\]\]. Inception events are covered in \[\[KID0003\]\].

## Read
## Update DID

Updating a did:keri DID is accomplished by publishing establishment events to the KEL for performing operations such as key rotation and updating signature thresholds, witnesses and delegates.

A detailed description of event types, their semantics and uses can be found in \[\[KID0003\]\].

## Deactivate DID

Deactivation of a did:keri DID consists of rotation to 0 controlling keys, which terminates the ability to recover the identifier and indicates that the identifier has been abandoned. Identifiers which are delegated to by an abandoned Identifier are also considered abandoned (delegating Ixn events can no longer be created).

Detailed steps are specified in \[\[KID0003\]\].

## Resolve DID

In order to resolve a DID into a DID Document, the key event log (KEL) must be discovered using one of the
following three alternatives. The selection of one mechanism over the other will depend on the use case.

* Using Out Of Band Introductions (OOBI): leverage native KERI introductions (OOBI and percolated discovery).
* Using Watcher Integration: based on the availability of Watchers or Super Watcher at the ecosystem in place.
* Using a Self-Addressing approach: valid for effective non transferable AIDs (no key rotation); useful as ephemeral DID.

Steps to resolve a \`did:keri:$PREFIX\` DID:

Expand All @@ -234,18 +253,6 @@ Steps to resolve a \`did:keri:$PREFIX\` DID:

Establishment of control authority can be done independently of DID document contents, as long as the Key State is provided in the DID Document Metadata. See [Resolver Metadata]().

## Update

Updating a did:keri DID is accomplished by publishing establishment events to the KEL for performing operations such as key rotation and updating signature thresholds, witnesses and delegates.

A detailed description of event types, their semantics and uses can be found in \[\[KID0003\]\].

## Deactivate

Deactivation of a did:keri DID consists of rotation to 0 controlling keys, which terminates the ability to recover the identifier and indicates that the identifier has been abandoned. Identifiers which are delegated to by an abandoned Identifier are also considered abandoned (delegating Ixn events can no longer be created).

Detailed steps are specified in \[\[KID0003\]\].

# Privacy Considerations

A breakdown of the privacy considerations from \[\[RFC6973\]\] section 5 is provided below.
Expand Down