Mapping the Identity Ecosystem Framework ‘A Whiter Shade of Gray” – (Input for NSTIC Plenary Next Week)

Session Topic: “A Whiter Shade of Gray” - Mapping the Identity Ecosystem Framework (Input for NSTIC Plenary Next Week)

Thursday 1D

Convener: Peter Brown

Notes-taker(s): Eric Scace, Peter Brown

Tags for the session - technology discussed/ideas considered: NSTIC; Identity Ecosystem; Terminology; Mapping; Frameworks;

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

Peter explained the genesis of this conversation. It started as an informal lunchtime discussion the previous day about whether “Framework” in the two concepts “Trust Framework” and Identity Ecosystem Framework” meant the same thing and whether clarifying any differences would give insight into the conceptual model for the proposed NSTIC identity ecosystem framework.

That conversation continued later that day and looked at all the NSTIC governance documents, particularly the terms used. The conclusion was that, in order to avoid confusion with use of the term in “Trust Frameworks”, we would analyse what the term “Identity Ecosystem Framework” was actually intended to convey and concluded that it is a set of guiding principles, normative prescriptions and practices. These cover:

- Liability protection for individuals (as well as work needed on clarifying what ‘liability’ implies);

- A “baseline for trust frameworks”;

- Ensure compliance with FIP/Ps and prevent PI re-aggregation and correlation;

- Compliance criteria for service providers seeking an ecosystem Trustmark;

- Accountability for, and Remediation following, fraudulent issuance and use of (trusted) credentials;

- Operating Procedures;

- Requirements for Accreditation authorities;

- Responsibilities of the Steering Group to administer, curate and manage policies and standards for the ecosystem;

- Steering Group to “confirm requirements with a broad group of stakeholders”

The placeholder name for this collection was “NERDs”.

Eric Scace continued…

Definitions:

1. The Identity Ecosystem contains "white" entities:

o Whose interactions with each other fully comply with the IDESG NERDs; and,

o Whose behavior, as seen by an outside observer, fully comply with the NERDs; and,

o Which are currently certified (or otherwise measured by an outside, qualified entity) as fully compliant, and may thereby carry a "white flag".

2. The Ecosystem likely contains "black" entities:

o Whose behavior be design is intended to be malicious.

3. The Ecosystem likely contains "gray" entities:

o Whose interactions with any other entity (white, gray or black) may functionally comply with interoperability specifications of the NERDs; and,

o Whose behavior, as seen by an outside observer, may not comply with the NERDs;

o Which are currently not certified as fully compliant.

Observations:

1. The subset of the Ecosystem containing only white entities should be sufficient to meet the NSTIC goals.

2. An organization may operate both white and gray entities.

3. Gray entities may interwork with white entities:

o Interworking does not, by its existence, cause a white entity to become gray.

o The flow of attribute or persona ("persona info") from gray to white does not cause the white entity to become gray, as long as the Persona Info is treated in compliance with the NERDS upon receipt by the white entity.

o The flow of Persona Info from white to gray may cause the white entity to no longer comply with the NERDs and thereby become gray. The circumstances when an outside observer can determine such a non-compliant flow no causes a white entity to become gray (and thereby lose its White Flag) shall be included in the NERDs.

4. Errors (instances when an entity or interaction does not comply with the NERDs) occur without malicious intent.

o NERDs and their implementation shall be error-tolerant. A defined threshold of errors shall be acceptable by design.

o White entities do not lose their White Flag if errors remain below threshold.

5. Malicious penetrations occur.

o A black entity may falsely carry a White Flag. The NERDs shall tolerate this event.

o The carriage of a White Flag by a otherwise-gray entity makes that entity black.

o A white entity (even a white entity carrying a White Flag) or gray entity may be penetrated and its operations may thereby become black.

o The NERDs shall tolerate penetrations and false white flags.

The subsequent discussion covered:

The value of talking about an ecosystem is precisely that ecosystems contain parasitical or destructive bodies that need to be handled. While no-one in a normative framework is going to “fess and sign up” as a ‘black entity’, they can nonetheless be identified within an ecosystem. Whilst the designation “ecosystem” works well for IDESG, the idea that this ecosystem can be “steered” by a Steering Group is less obvious.

If the ecosystem is built on stakeholders being involved in different ‘organisms’ of the ecosystem (such as Trust Frameworks), how do the stakeholder groups work in IDESG? The current breakdown is a purely functional, if not totally artificial, choice of groupings that seem to bring together the most important groups. The long ter success of the IDESG however will come about through organic growth from within the ecosystem, not from imposition from on-high.

One major concern is incentives: where is the incentive for the honorably “good guys, white entities” (who are already trusted, well-known, and with high reputations among stakeholders who are important for them) to seek certification within Frameworks that might also be populated by entities with lesser reputations?

While a ‘white entity’ might receive and handle, for example, attributes acquired from a gray entity – and subsequently handle them as would be appropriate for a white entity, what happens if a white entity hands off attributes to a gray entity? Would this also be OK? How?

General conclusion is the need for the ecosystem to be error and fault tolerant, permissive in inbound traffic and strict in outbound traffic (some similarities with early days of the WWW). Could there be two types and level of Trustmark? A first, high-level, bare-bones Trustmark valid across the board; a second one that is more detailed and Trust Framework specific. The main issue is transparency and being able to determine – whatever the characteristics of the specific Trustmark – what it stands for and allows.

Is there too much emphasis on the Trustmark? What is really important is reputation, less the specific evidence as that is often context specific.