Digital Identity

2 definitions of Digital Identity defined here.

Depends on context which is correct.


Digital Identity - Wikipedia.org 

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 


Modern Identity definitions focus on Digital Identity as an implementation of 2 key concepts:

Self Sovereign identity ( SSI )

Decentralized Identity Documents ( DID ) as a standard to define an SSI implementation


Trends in Digital Identity

https://www.thalesgroup.com/en/markets/digital-identity-and-security/government/identity/digital-identity-services/trends

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 

https://www.zdnet.com/article/identity-management-101-how-digital-identity-works/


From the article .. the key to Digital Identity ...

"It comes down to a way to federate identity across lots of different organizations," responded Hank Thomas, CEO of security VC Strategic Cyber Ventures LLC.  "That comes back to people having to work together, and trust each other that, once one person has proven that someone is someone, that other organization is going to have the same level of trust in the same thing. There's ways to do that; it's just that that trust isn't necessarily there yet. Maybe it's for compliance reasons, and for other reasons."


which logically leads to standards on: 


Self-Sovereign Identity ( SSI )


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

by Christopher Allen

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 membership18. 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.


Potential Benefits for Digital Identities


Benefits for Individuals

  1. User managed data privacy controls for identity, credentials
  2. Better protection for identity and data theft
  3. Optional automated consent history
  4. Better service and efficiencies
  5. Simpler compliance with regulations & standards
  6. Improved transparency & accuracy using blockchain history
  7. Easier identity & credentials proof sharing with less data sharing from wallet applications
  8. Improved reliability with automated agents, secure digital wallets
  9. Support for digital identity & credentials  recovery

Benefits for Organizations

  1. Foundation for other Digital Government services
  2. Automatically verifiable identities and credentials
  3. Improved service levels and times for users, firms
  4. Improved cost, resource  efficiencies for State agencies
  5. Verifiable digital signatures for transactions, documents
  6. Improved security & data privacy
  7. Simpler compliance with regulations & standards
  8. Improved transparency & accuracy using blockchain history
  9. Fraud reductions possible


Decentralized Identity Document ( DID )

W3C standards

https://www.w3.org/TR/did-core/

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

The example DID above resolves to a DID document. A DID document contains information associated with the DID, such as ways to cryptographically authenticate the DID controller, as well as services that can be used to interact with the DID subject.
EXAMPLE 2: Minimal self-managed DID document

{
  "@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.

GoalDescription
DecentralizationEliminate the requirement for centralized authorities or single point failure in identifier management, including the registration of globally unique identifiers, public verification keys, service endpoints, and other metadata.
ControlGive entities, both human and non-human, the power to directly control their digital identifiers without the need to rely on external authorities.
PrivacyEnable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data.
SecurityEnable sufficient security for requesting parties to depend on DID documents for their required level of assurance.
Proof-basedEnable DID controllers to provide cryptographic proof when interacting with other entities.
DiscoverabilityMake it possible for entities to discover DIDs for other entities, to learn more about or interact with those entities.
InteroperabilityUse interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability.
PortabilityBe system- and network-independent and enable entities to use their digital identifiers with any system that supports DIDs and DID methods.
SimplicityFavor a reduced set of simple features to make the technology easier to understand, implement, and deploy.
ExtensibilityWhere possible, enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity.


DID Architecture 


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

Figure 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.


DID Use Cases

https://w3c.github.io/did-use-cases/

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 

https://w3c-ccg.github.io/did-primer/


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 )



90417364-e1c87500-e0b3-11ea-8c9c-0255fb9b7bb1.png


Automation of Digital Trust on identity Blockchain Networks