Talk:Trustmark Evolving Design Pattern

Ann Racuya-Robbins

What makes the pattern an evolving pattern?

tomj response

time and changing circumstances. At least with respect to one trust mark.

See this section https://www.idecosystem.org/wiki/Trustmark_Evolving_Pattern#Evolution_of_a_Trustmark

I can see you parsed the term in a different way than I wrote it. The Trustmark evolution is the pattern. Patterns too should evolve, but that is treated at a higher level.

noreen response

From my Sept 19 email to Tom: Is "Evolving" an industry term or just one we are using? I am curious because it implies that it eventually climbs to a higher state while in our discussions we've been talking about it being more flexible, able to move between anonymous, pseudonymous and identified states and back again, seamlessly and in either direction.

tomj

Flexibility between different "Levels of Authentication (LOA)" or in the Trust Elevation Use Case are important. Please help me understand how to make that more clear. I disagree that it should be seamless. IMHO we need user consent to move to higher LOA. I also disagree that in a given interaction that it can move "back" It is practically impossible and sometimes illegal to ask a relying party during an interaction to "forget" stuff. That does not mean that a different interaction session could not be instantiated at any time with a lower LOA; but that would not be seamless.

Noreen Whysel

I made some very minor spelling and grammar corrections per my Sept 19 email to Tom.

These were my notes on the Usability Considerations:

This section should outline considerations that are specific to the design pattern. I would look at these specifically against Jakob Nielsen's usability heuristics. The evolving trustwork pattern should have:

• an indicator of the current trust state, such as a persistent icon or login link state that serves as a counter part to the RPs state indicator (eg the lock icon in the location bar)

Example use: text next to the Log Out link displaying current state (anonymous, pseudonym, verified ID)

• link to help text explaining what the states mean
• plain language alerts when conditions change

Example: a process that requires a verified identity versus a switch to a less secure state where user would be prompted to change their status as they leave a secure state.

tomj

See this page as a response to some of Noreen's comments about having a common list of definitions. Common to any Internet Identity Ecosystem

The first thing to notice about this and Noreen's comment above is that the terms {anonymous, pseudonymous, verified ID} as states are only aspirational. There exists no known technology to provide any of them in any absolute sense. Some limitations to each are:

1. anonymous interactions still require an endpoint address, e.g. an IP address, which can be linked to the user.
2. pseudonymous interactions are generally indistinguishable from other states by the relying party except where the user intent is made plain, which is not well defined at this point.
3. verified IDs are generally only approximations of reality. They can be spoofed by sufficiently motivated adversaries.