Page History

...

https://en.wikipedia.org/wiki/Digital_identity

A digital identity is information on an entity used by computer systems to represent an external agent. That agent may be a person, organization, application, or device. ISO/IEC 24760-1 defines identity as "set of attributes related to an entity".^[1]

The information contained in a digital identity allows for assessment and authentication of a user interacting with a business system on the web, without the involvement of human operators. Digital identities allow our access to computers and the services they provide to be automated, and make it possible for computers to mediate relationships.

The term "digital identity" also denotes certain aspects of civil and personal identity that have resulted from the widespread use of identity information to represent people in an acceptable trusted digital format in computer systems.

According to Feher's academic approach: digital identity "refers to the digital data corpus being built by users and digital systems" ^[2]

Digital identity is now often used in ways that require data about persons stored in computer systems to be linked to their civil, or national, identities. Furthermore, the use of digital identities are now so widespread that many discussions refer to "digital identity" as the entire collection of information generated by a person’s online activity. This includes usernames and passwords, online search activities, birth date, social security, and purchasing history.^[3] Especially where that information is publicly available and not anonymized, and can be used by others to discover that person's civil identity. In this wider sense, a digital identity is a version, or facet, of a person's social identity. This may also be referred to as an online identity.^[4] With self-sovereign identity (SSI) the user has a means of generating and controlling unique identifiers as well as some facility to store identity data.

The legal and social effects of digital identity are complex and challenging. However, they are simply a consequence of the increasing use of computers, and the need to provide computers with information that can be used to identify external agents.

Digital Identity as a synonym for Self Sovereign Identity 

...

Forces driving digital identity include:

We expect to see:

1. More mobility and access to the Internet
2. Greater demand for security and trust
3. An accelerating shift towards smart cities
4. More calls for public supervision of digital identification systems

5. Even more National ID card and eID programs​, national ID ​​initiatives, and implementations

How Digital Identity Management works - article 

...

self-sovereign identity requires that users be the rulers of their own identity.

For self-sovereign identity, which can be defined as a lifetime portable digital identity that does not depend on any centralized authority, we need a new class of identifier that fulfills all four requirements: persistence, global resolvability, cryptographic verifiability, and decentralization.

The Path to Self-Sovereign Identity - article

...

http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html

Self-sovereign identity is the next step beyond user-centric identity and that means it begins at the same place: the user must be central to the administration of identity. That requires not just the interoperability of a user’s identity across multiple locations, with the user’s consent, but also true user control of that digital identity, creating user autonomy. To accomplish this, a self-sovereign identity must be transportable; it can’t be locked down to one site or locale.

A self-sovereign identity must also allow ordinary users to make claims, which could include personally identifying information or facts about personal capability or group membership¹⁸. It can even contain information about the user that was asserted by other persons or groups.

Decentralized Identity Documents ( DID ) are a standard way to define a Self Sovereign Identity.

...

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URLs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Each DID document can express cryptographic material, verification methods, or service endpoints, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Service endpoints enable trusted interactions associated with the DID subject. A DID document might contain semantics about the subject that it identifies. A DID document might contain the DID subject itself (e.g. a data model).

This document specifies a common data model, a URL format, and a set of operations for DIDs, DID documents, and DID methods.

A DID example 

A DID is a simple text string consisting of three parts, the:

• URI scheme identifier (did)
• Identifier for the DID method
• DID method-specific identifier.

EXAMPLE 1: A simple example of a decentralized identifier (DID)

did:example:123456789abcdefghi

...

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  "service": [{
    // used to retrieve Verifiable Credentials associated with the DID
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

DID Goals

Decentralized Identifiers are a component of larger systems, such as the Verifiable Credentials ecosystem [VC-DATA-MODEL], which drove the design goals for this specification. This section summarizes the primary design goals for this specification.

DID Architecture 

This section provides a basic understanding of the major elements of DID architecture. Formal definitions of terms are provided in § 2. Terminology .

Image ModifiedFigure 1 The basic components of DID architecture.

• DIDs and DID URLs
  • A DID, or Decentralized Identifier, is a URI composed of three parts: the scheme "did:", a method identifier, and a unique, method-specific identifier generated by the DID method. DIDs are resolvable to DID documents. A DID URL extends the syntax of a basic DID to incorporate other standard URI components (path, query, fragment) in order to locate a particular resource—for example, a public key inside a DID document, or a resource available external to the DID document.
    
    
• DID Subjects
  • The subject of a DID is, by definition, the entity identified by the DID. The DID subject may also be the DID controller. Anything can be the subject of a DID: person, group, organization, physical thing, logical thing, etc.
    
    
• DID Controllers
  • The controller of a DID is the entity (person, organization, or autonomous software) that has the capability—as defined by a DID method—to make changes to a DID document. This capability is typically asserted by the control of a set of cryptographic keys used by software acting on behalf of the controller, though it may also be asserted via other mechanisms. Note that a DID may have more than one controller, and the controller(s) may include the DID subject.
    
    
• Verifiable Data Registries
  • In order to be resolvable to DID documents, DIDs are typically recorded on an underlying system or network of some kind. Regardless of the specific technology used, any such system that supports recording DIDs and returning data necessary to produce DID documents is called a verifiable data registry. Examples include distributed ledgers, decentralized file systems, databases of any kind, peer-to-peer networks, and other forms of trusted data storage.
    
    
• DID documents
  • DID documents contain metadata associated with a DID. They typically express verification methods (such as public keys) and services relevant to interactions with the DID subject. A DID document is serialized according to a particular syntax (see § 6. Core Representations). The DID itself is the value of the id property. The generic properties supported in a DID document are specified in § 5. Core Properties. The properties present in a DID document may be updated according to the applicable operations outlined in § 7. Methods .
• DID Methods
  • DID methods are the mechanism by which a particular type of DID and its associated DID document are created, resolved, updated, and deactivated using a particular verifiable data registry. DID methods are defined using separate DID method specifications (see § 7. Methods ).
    
    
• DID resolvers and DID resolution
  • A DID resolver is a software and/or hardware component that takes a DID (and associated input metadata) as input and produces a conforming DID document (and associated metadata) as output. This process is called DID resolution. The inputs and outputs of the DID resolution process are defined in § 8. Resolution . The specific steps for resolving a specific type of DID are defined by the relevant DID method specification. Additional considerations for implementing a DID resolver are discussed in [DID-RESOLUTION].
    
    
• DID URL dereferencers and DID URL dereferencing
  • A DID URL dereferencer is a software and/or hardware component that takes a DID URL (and associated input metadata) as input and produces a resource (and associated metadata) as output. This process is called DID URL dereferencing. The inputs and outputs of the DID URL dereferencing process are defined in § 8.2 DID URL Dereferencing . Additional considerations for implementing a DID URL dereferencer are discussed in [DID-RESOLUTION].
• Verifiable Credentials
  • Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.

...

This document sets out use cases and requirements for a new type of identifier that has 4 essential characteristics:

1. decentralized: there should be no central issuing agency;
2. persistent: the identifier should be inherently persistent, not requiring the continued operation of an underling organization;
3. cryptographically verifiable: it should be possible to prove control of the identifier cryptographically;
4. resolvable: it should be possible to discover metadata about the identifier.

Although existing identifiers may display some of these characteristics, none currently displays all four.

DID Primer - what they are, how to use 

...

A Decentralized Identifier (DID) is a new type of identifier that is globally unique, resolveable with high availability, and cryptographically verifiable. DIDs are typically associated with cryptographic material, such as public keys, and service endpoints, for establishing secure communication channels. DIDs are useful for any application that benefits from self-administered, cryptographically verifiable identifiers such as personal identifiers, organizational identifiers, and identifiers for Internet of Things scenarios. For example, current commercial deployments of W3C Verifiable Credentials heavily utilize Decentralized Identifiers to identify people, organizations, and things and to achieve a number of security and privacy-protecting guarantees. This document is an introduction to the concept of Decentralized Identifiers.

The need for globally unique identifiers that do not require a centralized registration authority is not new. UUIDs (Universally Unique Identifiers, also called GUIDs, Globally Unique Identifiers) were developed for this purpose in the 1980s and standardized first by the Open Software Foundation and then by IETF RFC 4122.

The need for persistent identifiers (identifiers that can be assigned once to an entity and never need to change) is also not new. This class of identifiers was standardized as URNs (Uniform Resource Names) first by IETF RFC 2141 and more recently by RFC 8141.

As a rule, however, UUIDs are not globally resolvable and URNs – if resolvable – require a centralized registration authority. In addition, neither UUIDs or URNs inherently address a third characteristic – the ability to cryptographically verify ownership of the identifier.

For self-sovereign identity, which can be defined as a lifetime portable digital identity that does not depend on any centralized authority, we need a new class of identifier that fulfills all four requirements: persistence, global resolvability, cryptographic verifiability, and decentralization.

Identity Blockchains ( Sovrin, Indy, etc )

...

Aries - a Universal Agent for Identity Blockchains

Trust Over IP ( TOIP )

Image Added

Automation of Digital Trust on identity Blockchain Networks

...