22B/ Identity Architecures - Developing a methology to evalueate characteristics

Identity Architectures: Developing a Methodology to Evaluate Different Identity Architecture Characteristics

Thursday 22B

Convener: Todd Gehrke, Trev Harmon

Notes-taker(s): Todd Gehrke

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

Session Context

This was a working session and conversation around developing some key properties of a “good” identity architecture. The goal was to go slightly beyond the simple issuer -> holder -> verifier and represent some of the components of the system

The context of the discussion was for a Non-Enterprise setting because including integration into the backend system made the problem space too complex.

We also want to be considering system that might fit within the ID2020 Alliance Manifesto https://id2020.org/manifesto

The focus was on Public and NGO sector use cases where there were transactional interactions.

Digital Identity Vital Signs

A set of 6 Identity System Characteristics in prioritized order. These items are derived from a much longer list, The goal is to use them as a starting point for a conversation.

Feedback:

• In the context of the underserved Population Accessibility should be higher on the list.

• It is best to not order the list. All are equally important

• Each item needs a clear definition, Security is too vague

• The meaning of all these words is key to understanding what you mean. Each one could be a 30 min or more conversation.

• Combining Transparency and Security might be enough to constitute Privacy Preserving

• James Manger : Usability

• 1. Fit for purpose. Good digital identities offer a reliable way for individuals to build trust in who they claim to be, to exercise their rights and freedoms, and/ordemonstrate their eligibility to access services.

• 2. Inclusive. Inclusive identity enable anyone who needs it to establish and use a digital identity, free from the risk of discrimination based on their identity-related data, and without facing authentication processes that exclude them.

• 3. Useful. Useful digital identities offer access to a wide range of useful services and interactions and are easy to establish and use.

• 4. Offers choice. Individuals have choice when they can see how systems use their data and are able to choose what data they share for which interaction, with whom and for how long.

• 5. Secure. Security includes protecting individuals, organizations, devices and infrastructure from identity

• From John W : From one of my deck’s. A slide on Privacy and Data Autonomy: A person maintains their privacy when they have the ability and power to choose what information about themselves to disclose, to whom, and for what reason. They are autonomous and have agency. When information about a person’s behaviour or performance is recorded by an organization (like at work or at school), an individual’s privacy is protected when they they know what information

Shared Link:

http://www3.weforum.org/docs/WEF_INSIGHT_REPORT_Digital%20Identity.pdf

Final unordered list created by the group:

• User Autonomy

• Privacy Preserving

• Interoperability & Portability

• Security (Anti-Honeypot)

• Population Accessibility

• Transparency

• Usability

Example architecture 1

The goal of this diagram is to represent multiple issues that issue credentials to a users handset. This is intended to be a starting point, or ideal architecture. We are disregarding fundamental elements such as guardianship and the details of backup and recovery. . .

Feedback:

• The diagram doesn't show a user (it is implied by the handset)

• The architecture diagram itself doesn’t tell us enough.

• We need to talk within the context of specific uses cases

• We need to talk about both the what and the how

• Public key and cryptography are part of the how and don’t belong on the diagram.

• An example of a challenge, here, is that User Control is essential, but has to be balanced against User Burden. (For typical uses of the term Usability, it is actually an additional, separate concern)

• How is Trust Registry different from the 'Publish Public Key' repository? The trust registry is the list of issuing authorities the verifier will respect. Could be included as part of the verifier . . .

Example architecture 2

This is an example drawn from Mobile Drivers License Initiative and a presentation given by John Wunderlich (Kantara)

https://www.securetechalliance.org/mobile-drivers-license-initiative/

Feedback:

• Overall the group thought this was an inadequate architecture because of the “phone home” component.

• The use of an oracle to validate the cradentail doesn’t remove the fact that there is tracing going on even though it’s not the same as going back to the original issuing authority.

• Dan B pointed out that this is like the approach that is much like the pattern used in Estonia e-Residency program. Using a single government issuer but a decentralized network of verifiers.

Example architecture 3

Credentials held on a cloud agent owned by the holder. User owns and provisions infrastructure provisioned in thor cloud account.

Feedback:

• Group was OK with this, didn’t have a lot of feedback.

Example architecture 4

Identity provider, government or private company, provides Identity as a service. Holder has control of credentials but may not have control of the infrastructure hosting the agent and storage services.

Feedback:

• Although this is likely to be the most common model the group did not feel this was a good architecture.