Page 39 - Implementation of Secure Authentication Technologies for Digital Financial Services

• The emergence of distributed ledger technology 3. PII Protection: DID architecture should enable
(DLT), sometimes referred to as blockchain tech- entities to control the identifiable data of their
nology, provides the opportunity for fully decen- digital identities, including minimal, selective, and
tralized identity management. In a decentralized progressive disclosure of attributes or other iden-
identity system, entities are free to use any shared tity data.
root of trust. Globally distributed ledgers (or a 4. Security: DID architecture should enable suffi-
decentralized P2P network that provides similar cient security for relying parties to depend on DID
capabilities) provide a means for managing a root records for their required level of assurance.
of trust with neither centralized authority nor a 5. Proof-based: DID architecture should enable an
single point of failure. In combination, DLTs and entity to provide cryptographic proof of authen-
decentralized identity systems enable any entity tication and proof of authorization rights.
to create and manage their own identifiers on any 6. Discoverability: DID architecture should make it
number of distributed, independent roots of trust. possible for entities to discover DIDs for other
• The entities are identified by decentralized iden- entities to learn more about or interact with those
tifiers (DIDs). They may authenticate via proofs entities.
(e.g., digital signatures, privacy-preserving bio- 7. Interoperability: DID architecture should use
metric protocols, etc.). DIDs point to DID Docu- interoperable standards so DID infrastructure can
ments. A DID Document contains a set of service make use of existing tools and software libraries
endpoints for interacting with the entity. Follow- designed for interoperability.
ing the dictums of Privacy by Design, each entity 8. Portability: DID architecture should be system and
may have as many DIDs as necessary, to respect network-independent and enable entities to use
the entity’s desired separation of identities, perso- their digital identities with any system that sup-
nas, and contexts. ports DIDs and DID Methods.
• To use a DID with a particular distributed ledger 9. Simplicity: To meet these design goals, DID archi-
or network requires defining a DID method in a tecture should be “as simple as possible but no
separate DID method specification. A DID method simpler”.
specifies the set of rules for how a DID is regis- 10. Extensibility: When possible, DID architecture
tered, resolved, updated, and revoked on that spe- should enable extensibility provided it does not
cific ledger or network. greatly hinder interoperability, portability, or sim-
• This design eliminates dependence on central- plicity.
ized registries for identifiers as well as centralized
certificate authorities for key management – the 6.7.6 DID Authentication
standard pattern in hierarchical PKI (public key DID Authentication [14] enables a DID Subject to
infrastructure). Because DIDs reside on a distrib- prove control over a DID during its interaction with
uted ledger, each entity may serve as its own root a relying party. The following general steps to be
authority – an architecture referred to as DPKI executed by the relying party include:
(decentralized PKI).
1. The relying party retrieves the DID Document
In general, DID design goals are the following [10]: associated with the DID Subject
2. The relying party uses the authentication prop-
1. Decentralization: DID architecture should elimi- erty of the DID Document to determine how to
nate the requirement for centralized authorities perform DID authentication, for example cryp-
or single points of failure in identity management, tographic signatures, proving control of a public
including the registration of globally unique iden- key or use of an authentication service endpoint
tifiers, public verification keys, service endpoints, 3. The relying party executes the authentication
and other metadata. mechanism provided
2. Entity control of identifiers: DID architecture
should give entities, both human and non-human, DID authentication should support web and mobile
the power to directly control their own digital flows.
identifiers without the need to rely on external
authorities.

Implementation of Secure Authentication Technologies for Digital Financial Services 37