This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 30 lines
!!! Overview
[{$pagename}] ([DIDs]) are a new type of identifier for verifiable, "[Self-Sovereign Identity]". [{$pagename}] are fully under the control of the [DID Subject], independent from any [centralized registry|Registration Authority], [identity provider|Identity Provider (IDP)], or [certificate authority|Certificate Authority].
[{$pagename}] are [URLs] that relate a [DID Subject] to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each [DID Document] contains at least three things: cryptographic material, authentication suites, and service endpoints. Cryptographic material combined with authentication suites provide a set of mechanisms to authenticate as the DID subject (e.g., public keys, pseudonymous biometric protocols, etc.). Service endpoints enable trusted interactions with the DID subject.
that does not require a centralized [Registration Authority] because it is registered with [Distributed Ledger Technology] or other form of [Decentralized system] network.Conventional [Identity Management Architectures] are based on centralized authorities such as corporate [Directory Services], [Certificate Authorities|Certificate Authority], or domain name registries. From the standpoint of [cryptographic] [trust] verification, each of these centralized authorities serves as its own [Trust Anchor]. To make [Identity Management Architectures] work across these systems requires implementing [Federated Identity Management].The emergence of [Distributed Ledger Technology] ([DLT]), sometimes referred to as blockchain technology, provides the opportunity to implement fully decentralized identity management. In this ecosystem, all participants with identities (called identity owners) share a common [Trust Anchor] in the form of a globally distributed ledger (or a decentralized [P2P] network that provides similar capabilities).Each identity owner can be identified on a ledger with a key-value pair. The index key is a [{$pagename}] and the value is its associated [DID descriptor object].
Together these form a [DID record].
Each [DID record] is [cryptographically|Cryptography] secured by [Private Keys] under the control of an identity owner (in the case of an owner-managed identity) or a [Custodian] (in the case of a [Custodian Managed Identity]).
A corresponding [Public Key] is published in the [DID descriptor object] using a key description.
A [DID descriptor object] may also contain a set of service [endpoints] for interacting with the identity owner. Following the dictums of [Privacy by Design], each identity owner may have as many [DID records] as necessary to respect the identity owner’s desired separation of identities, personas, and [contexts].
To use a [{$pagename}] with a particular distributed ledger or network requires defining a [DID method|DID method specification] specification.
This design eliminates dependence on centralized registries for identifiers as well as centralized [certificate authorities|Certificate Authority] for [Key Management]. With [DID records] on a distributed ledger, each identity owner may serve as its own [Trust Anchor]—an architecture referred to as [DPKI] ([Decentralized PKI|Decentralized Public Key Infrastructure]).
[{$pagename}]s resolve to [DDO]s ([DID descriptor objects]) prove ownership and control of a [{$pagename}].
Each [{$pagename}] uses a specific [{$pagename}] method, defined in a separate DID method specification, to define how the [{$pagename}] is registered, resolved, updated, and revoked on a specific [Distributed Ledger Technology] or network.
!! Motivations for [{$pagename}]s
The growing need for a [{$pagename}] has produced three specific requirements for a new type of [URI] that fits within the [URI]/[URL]/[URN] architecture, albeit in a less than traditional way:
* A [URI] that is persistent like a [URN] yet can be resolved or de-referenced to locate a [resource] like a [URL]. In essence, a [DID] is a [URI] that serves both functions.
* A [URI] that does not require a [centralized authority|Administrative Identity] to register, resolve, update, or revoke. The overwhelming majority of [URIs] today are based on [DNS] names or [IP] addresses that depend on centralized authorities for registration and ultimate control. DIDs can be created and managed without any such authority.
* A [URI] whose ownership and associated metadata, including public keys, can be cryptographically verified. Control of DIDs and DDOs leverages the same [public Key]/[private Key] [cryptography] as [Distributed Ledger Technology].
!! [Sovrin] and [{$pagename}]
[Sovrin] defines [{$pagename}] as identifiers that are globally unique and resolvable (via a [Distributed Ledger Technology]) without requiring any centralized resolution authority. DIDs are specified in the [DID Data Model and Generic Syntax specification|https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/draft-documents/did-implementer-draft-10.md|target='_blank']!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]