Page 33 - FIGI: e-KYC use cases in digital financial services

a) Decentralization: DID architecture should elimi- a root of trust with neither centralized authority
nate the requirement for centralized authorities nor a single point of failure. In combination, DLTs
or single points of failure in identity management, and decentralized identity systems enable any
including the registration of globally unique iden- entity to create and manage their own identifiers
tifiers, public verification keys, service endpoints, on any number of distributed, independent roots
and other metadata. of trust.
b) Entity control of identifiers: DID architecture b) The entities are identified by decentralized iden-
should give entities, both human and non-hu- tifiers (DIDs). They may authenticate via proofs
man, the power to directly control their own digi- (e.g., digital signatures, privacy-preserving bio-
tal identifiers without the need to rely on external metric protocols, etc.). DIDs point to DID Docu-
authorities. ments. A DID Document contains a set of service
c) Personal Identifiable Information Protection: DID endpoints for interacting with the entity. Follow-
architecture should enable entities to control the ing the dictums of Privacy by Design, each entity
identifiable data of their digital identities, includ- may have as many DIDs as necessary, to respect
ing minimal, selective, and progressive disclosure the entity's desired separation of identities, per-
of attributes or other identity data. sonas, and contexts.
d) Security: DID architecture should enable suffi- c) To use a DID with a particular distributed ledger
cient security for relying parties to depend on or network requires defining a DID method in a
DID records for their required level of assurance. separate DID method specification. A DID meth-
e) Proof-based: DID architecture should enable an od specifies the set of rules for how a DID is reg-
entity to provide cryptographic proof of authen- istered, resolved, updated, and revoked on that
tication and proof of authorization rights. specific ledger or network.
f) Discoverability: DID architecture should make d) This design eliminates dependence on cen-
it possible for entities to discover DIDs for oth- tralized registries for identifiers as well as cen-
er entities to learn more about or interact with tralized certificate authorities for key manage-
those entities. ment—the standard pattern in hierarchical PKI
g) Interoperability: DID architecture should use (public key infrastructure). Because DIDs reside
interoperable standards so DID infrastructure can on a distributed ledger, each entity may serve as
make use of existing tools and software libraries its own root authority – an architecture referred
designed for interoperability. to as DPKI (decentralized PKI).
h) Portability: DID architecture should be system
and network-independent and enable entities to
use their digital identities with any system that 7�4 DID Requirements and Authentication
supports DIDs and DID Methods. Some requirements proposed for DIDs are as follows:
i) Simplicity: To meet these design goals, DID archi-
tecture should be "as simple as possible but no a) Entities must be able to self-manage their own
simpler". DIDs on a distributed ledger, using a DID method.
j) Extensibility: When possible, DID architecture b) The DID method must conform to W3C working
should enable extensibility provided it does not draft "Decentralized Identifiers (DIDs) v1.0".
greatly hinder interoperability, portability, or sim- c) the DID method must ensure the Holder/User
plicity. is the exclusive DID owner, (e.g., the private key
corresponding to the public key used to authen-
From the W3C Decentralized Identifier draft spec- ticate the DID controller).
ification: d) when assisted by a third party in the DID cre-
ation process, any party must always maintain
a) The emergence of distributed ledger technology the DID's sole control.
(DLT), sometimes referred to as blockchain tech- e) A DID shall be anchored on a distributed ledger.
nology, provides the opportunity for fully decen- f) A DID must be universally resolvable to its corre-
tralized identity management. In a decentralized sponding DID document.
identity system, entities are free to use any shared g) The DID document may be produced upon
root of trust. Globally distributed ledgers (or a demand when dereferencing the DID; and
decentralized P2P network that provides sim- h) A DID document for a natural person must not
ilar capabilities) provide a means for managing be stored in a distributed ledger, except for its

e-KYC use cases in digital financial services 31