ID2020 Technical Requirements
V1.01
2019-04-28
Contributors:
Adam Cooper, ID2020
Brian Behlendorf, Linux Foundation
Daniel Bachenheimer, Accenture
Ankur Patel, MicrosoftThomas Hardjono, MITDon Thibeau, Open Identity Foundation
Dakota Gruener, ID2020

Key Requirements
Requirement

Commentary

1

APPLICABILITY

1.1

Must be useful in both physical, offlineand online scenarios.

Must take into account of, but not limited tothe following:
1. Power may not be available tosupport identity transaction(s)2. Wired or wireless data or cellular
services may not be available tocomplete identity transaction(s)3. Service requestor may not have aportable device
4. Service provider may have limited
IT infrastructure

1.2

Must be resilient / usable in “rugged”
environments.

Field equipment must be able to sustain
long-term use in rugged environments forperiods of time that exceed any pilot phasefor example multiple years beyond
implementation.

1.3

Must be cost effective across all aspectsof the identity lifecycle.

Where the identity lifecycle is defined as:
1. Identity Proofing
2. Issuance

Version 1.0

Page 1 of 103. Authentication
4. Authorization
5. ID management (includingRecovery)
1.4

Must be easy for ​end-users​ to use
throughout the identity lifecycle andrequire minimal user education

A human-centric design should beadopted.

1.5

Must be easy to implement by theRelying Party and have a clear
explanation of cost as well as
implications for the use of digital identity.

The Relying Party should be able to easily
implement due to open standards, openAPIs, and commonly available skills (forexample OIDC and OAuth).
The cost of implementation should beclearly defined for a Relying Party as wellas the level of trust that can be placed inassertions of identity based on either legal
or trust frameworks (for example).

1.6

Must be easy for ​implementing agentsto use and to explain throughout theidentity lifecycle

2

IDENTIFICATION AND VERIFICATION

2.1

Should be able to create a unique digital
identity quickly and at low cost.

The identification process is inherently
costly as it involves deduplication of thespecified population in order to create aunique digital identity; in certain use cases
uniqueness is not required.

2.2

Must support multiple forms ofidentification and proofing.

Biometrics can be used alone or, inconjunction with other forms of identity
claims where the user will be bound to theclaim once authenticated.

A human-centric design should beadopted.

Refugees often have no identity
documents and a percentage of those that
do may not be possess legitimate
documents.
2.3

Must support manual override in caseidentity cannot be proven.

There should be a framework to support
manual override but this should not be partof the foundational technical system.
An audit trail should be maintained wheremanual override is applied.

Version 1.0

Page 2 of 10

2.4

Registration must be available offline aswell as online.

Registration may be initiated offline by theuser, but identity proofing will requireconnectivity for the registration or agent
system. Similarly, credential issuance
may be offline but reconciled when there isconnectivity (e.g. may result in a credentialrevocation).

2.5

Should support the ability for the subject
to create and use pseudonymous identity

Where possible, and permitted in thecontext of the of the identity system being
implemented, the subject should have theability to create and use pseudonymousidentity.

2.6

A minimum client profile must be defined. The client profile should observe theprinciple of data minimisation and ensurethat a clear purpose is defined for eachdata item to be collected, processed andstored in order to identify the subject.

2.7

A failure mode should be included where
the subject is not able to follow thenormal procedure for identification.

For example, where identification would
normally require fingerprints from bothhands and the subject has previously
suffered the loss of a hand. In this casefailure mode procedures should be inplace so that individuals are not excluded
or disadvantaged unnecessarily.

2.8

Address Bias in Biometrics

Biometrics recognition systems trainedusing data collected from a specificdemographic profile (age, gender,ethnicity, glasses wearers, etc.) have beenshown to have a bias. The training set
should be reflective of production
demographics.
Best practice should be observed. Poor
data will affect accuracy e.g. the training
data set should avoid bias.
In production a performance analysis
should be conducted to ensure that thesystem remains within specification.

2.9

Duplicate Prevention

Provision should be made in the system
issuing claims (regardless ofVersion 1.0

Page 3 of 10

pseudonymity or anonymity) to identify
duplicates either at the time of registration,or by application of a batch processing
process (as a consequence of offline ordecentralisation solutions). The need forthis feature is dependant on therequirements of the system.
In the case of offline or batch processing
there should be provision for mitigatingprocesses where duplicate claims aredetected in order to prevent identity fraud
or the existence of duplicate identities
based on biometric identification or due toa clash in the generation of identifiers (e.g.
GUIDs).
3AUTHENTICATION

3.1

Must support multiple forms of pluggable
authentication, including biometrics andcryptographic secrets

Authentication Assurance Level attributes
should be available to the service provider(relying party).

3.2

Should support multiple “tokens” andsmart phones / PCs

There should not be assumptions
regarding the devices available toindividuals with regards to authentication.
Multiple methods of authentication should
be available to ensure inclusivity.

3.3

Alternative methods of authentication in
support of failure modes

Where the subject is unable to use theprimary method of authentication (e.g. abiometric) an alternative authentication
method should be provided of at least
equivalent in strength to the primarymethod.

3.4

Authentication should be availableoffline.

Offline authentication should be possible
but to check the validity of an identity may
require an online validation check to an
authoritative source. An identity token may
require an online validation check or acheck against a local copy of same.

4PRIVACY AND CONTROL

4.1

Must allow the user to have granular
control over the sharing of personal data

Version 1.0

Users should have the ability to allow ordeny the sharing of personal data at thepoint of request, as a preference before
Page 4 of 10

request, or at a later point in time, bygiving their informed consent.
4.2

Must allow users to have visibility andaudit-ability of consent and accesses(i.e., sharing with 3​rd​ parties), andrevocation of consent

Users should have the ability to view audit
data regarding the use of their identity,especially when consent is revoked.
Consent, visibility of consent / use /withdrawal of identity information, ability torevoke consent.
Systems should actively alert the userwhen something [data] they haveconsented to is used for a derivative use.
Consent receipts must be recoverable.

4.3

Must allow custodianship / guardianshipto be exercised for applicable persons.

Must allow parents / legal guardians /caregivers to be able to take appropriate
action on behalf of a minor / person being
cared for.
All parties must have registered identities
within the system. The rules for how therelationship is established between theparties is out of scope for theserequirements but should be supported
technically by metadata within the identity
system.
This metadata should describe the type ofrelationship (for example parent / child or
caregiver / dependent) between the parties
and any ancillary information that may
assist a Relying Party with authorisationsuch as the method and verification of therepresentation being described.

4.4

Must have controls against the act by anadversary to access, delete, or modify
the identity.

Security controls must ensure theconfidentiality and integrity of identity data,
at rest or in transit, and processes put inplace to protect the underlying identity
system from unauthorised access orabuse. Baseline standards for data
security such as ISO/IEC 27001 and theimplementation of an information security
management system, or equivalent,

Version 1.0

Page 5 of 10

should be considered where appropriate.
Users should be provided with aneasy-to-use response mechanism.
In the case of a breach at the issuingauthority (credential and/or claim) theuser(s) and any relying parties must bealerted electronically by a method
previously agreed with those parties.
4.5

Processing, retention, and sharing ofidentity data shall be transparent to thesubject except where legal provisions
prevents it.

Subjects should expect to be able toaccess information electronically when andhow they want. This should include
information regarding how, when and by
who their identity data has been accessed.
This should be inline with and respect the"transparency and access" principle."

4.6

Privacy of the Subject must be protected
throughout the identity lifecycle.

The principles of Privacy by Design andData Minimisation should be observed asshould the spirit of GDPR even if that
Regulation is not enforced by law for aparticular implementation. There should bea clear explanation of how the identity
system being implemented will support
GDPR (as a baseline).

4.7

PII should not be immutable and therights of the user observed.

The Right to be Forgotten should be usedliberally. PII should not be immutable inthe context of the identity system being
implemented.

4.8

Data accuracy should be a priority andusers should be able to view and amend
errors or make required updates.

Subject should be able to update
erroneous, out of date, or poor quality data
to reduce identity errors.

4.9

The sharing of data should be avoided
where aggregate computations aresufficient.

Approve only insights that are aggregatecomputations on personal data, yielding
aggregate answers that reduce or
eliminate the possibility of re-identificationof an individual through correlation of data.

4.10

Change of identity

Subjects should be able to update theiridentity data (e.g. name, date of birth) andwhere necessary biometric data.
Version 1.0

Page 6 of 10

Where the user is unable to authenticate
as part of the update process alternativemodes of authentication should beprovided. For example, where a biometricis used as the normal method ofauthentication a fall-back method such asa mobile OTP could be utilised.
All changes should be auditable andverifiable by the user.
Relying parties must be informed of themodality of authentication used in thecontext of change of identity, for example,biometric, or PIN. This will allow relying
parties to manage risk when thesechanges are made by users.
5ATTESTATIONS AND TRUST

5.1

Must be able to store, and manage many
attestations from governments andorganizations

Privacy model must be easy to understandby the user, relying party and trust provider(including independent auditors).
The issuance system must support
issuance of claims by many parties suchas governments and organisations.
The system must support a subject being
able to present claims issued to themwithout the risk of disintermediation.
The system must support verification ofclaims by the issuer without the risk of
disintermediation.
The system should provide a claims
receipt for issuance, presentation andverification.

5.2

Must be able to prove that attestations
are genuine, untampered, pertains to therecipient and current status is active / notrevokedVersion 1.0

Identity related operations (of the system)must provide the ability to verify theissuance, presentation, and current state(e.g.validity) of any claim.
Page 7 of 10

Attestations should be “Provable": not justauthenticity and veracity of the attestation,
but the fact that it pertains to the recipient.
5.3

Must be able to attest how the identity
proofing was performed.

Metadata should be provided to identify
not only how the proofing was performed
but also the Identity Assurance Levelattained as a consequence of that proofing
process and subsequent issuance ofcredentials.

5.4

Must not require point to point trust
agreements across parties

Data sharing agreements must not berequired where the subject is in control ofthe data.

5.5

Participation in Trust Frameworks

The system must be able to participate ina trust framework where a governancemodel is required to codify access rights,consensus, identity resolution, etc.
The system must be able to support
interoperability based on recognised
standards to ensure addressability andverifiability of the presented claim.
If such a framework is created, it must not
impose mandatory participation for any ofthe basic functions of the system. Instead,
it should be a set ofstandards/components parties canleverage to ascertain whether anotherentity or proof is valid within its
context/rules.

6

INTEROPERABILITY

6.1

Where possible / practical should be
implemented using open source
software.

Open source software and open standardsfor implementation should be adopted
where appropriate although it isrecognised that in some cases this is notpossible (e.g. biometric devices). As aminimum open standards should beadopted at the edge of solution
components to ensure interoperability andavoid vendor lock-in.

6.2

Must support open APIs for access toOpen APIs must be provided for all system

Version 1.0

Page 8 of 10

data and integration with other identity
system components / vendors.

components to ensure interoperability but
also portability should components and/orvendors be replaced or Subjects requiretheir data to be extracted and/or removed.

6.3

Each solution element used in
implementing the Identity Lifecycle
should be open standards based in orderto minimize vendor lock-in

Barriers to vendor portability should be
removed where possible as described in
6.1 and 6.2 above. “Can you fire yourservice provider”, is a good litmus test fortrue vendor portability.

6.4

Must be able to export the data in amachine-readable form.

Data when exported, as referred to in 6.2,
should itself be provided in an open
standard machine-readable format
enabling ease of import into a newsystem/component.

7

RECOVERY AND REDRESS

7.1

Must support secure recovery if one ormore identity attributes is / arecompromised / lostProviders of identity attributes (dataregarding the Subject including keys)
should provide tools and/or support for
secure recovery should compromise
and/or loss of data be experienced.

7.2

Must support redress if identity iscompromised or is inaccurate

Rules outlining mechanisms for redress
should be included in either national law or
as part of any agreement between theSubject and any identity proofing entity
should that entity be the cause of any data
error(s), breach or identity theft.

7.3

Must provide at least one key custodianin a recovery scheme

At least one custodian must exist for key
recovery for the identity system being
implemented and that this custodian isindependent of Government wherepossible.
In cases where Government is the onlyoption available, assurances regarding
privacy and consumer protection must be
clearly made. A statement of intent
regarding the future availability of
non-government custodians should also
be made regardless of whether thegovernment is the initial custodian.
Future solutions that support multiple

Version 1.0

Page 9 of 10

custodians should be considered whenproven in the field.

Recommendations
Recommendation
R1

The system must observe the law as it applies to the deployment either bygeography or as a consequence of the users affected by the system.

R2

Complex legal frameworks should be avoided particularly where the user is thenexus between two or more parties.

Version 1.0

Page 10 of 10