Difference between revisions of "Identity Model Overview"

Revision as of 16:18, 3 September 2024

Meme - the Basic Idea

• Every digital entity or human user on the internet needs to have a name or other identifier before any meaningful conversation about that thing is possible.

• Once an identifier is established attributes, behaviors or documents can be associated to that identifier.

• All User Private Information held by any digital entity on the internet (called a User Object below) is subject to examination and control by the user.

• Creating a language for creating a Design Pattern has been a challenge ever since communities grew beyond the tribe. This paper represents a new way of looking at identity, as a collection of Identifier, Attributes, and Behaviors none of which may be released to any digital entity without the user's explicit consent.

• The intended audience of this page is for decision makers and so has limited technical details. Click on the Identity Model for a complete technical description with all of the technical details.

Context

The Identity Ecosystem Framework (IDEF) core Baseline Functional Requirements v1.0 (BFR) serves as the basis for this model.

In any IDEF compliant ecosystem there are three broad categories of digital entities that require the identity of users.

1. The User Agent that faithfully expresses the intent of the user to the other entities.
2. The Identifier or Attribute Providers (IAP) that have a close relationship to the user.
3. The Relying Party that holds data about the User (Subject) in their database (User Object) and must allow users continuing access to any User Private Information and provide redress of user concerns about the data.
   1. Relying parties may chose to have their own authentication schemes where the user is expected to maintain their credential,
   2. To be IDEF compliant, Relying parties must enable authentication with appropriate third party Identity Providers in some way.

Problems to be Solved

The are all problem that Digital Entities have faced in implementing the Baseline Functional Requirements (shown in parentheses.)

1. There is no clear and consistent method for any Digital Entity to understand how to structure a consent request or even how the user and the Digital Entity could agree on what names and meaning of the data might be.(Usable Req 7).
2. Users are having challenges understanding what attributes are requested and why. The difference between this best practice and the above usability requirement is not clear.(Usable Best Practice A)
3. Separating User Private Information into identity and attribute buckets is not clear. Some sort of data model would help to make this clear. The following are some of the concerns that are not addressed in the BFR. (Privacy Req 15).
   1. Knowledge Based Authentication (KBA) is created on the concept that any attribute can be used in an authentication process.
   2. It has been shown that just a user's 5 digit zip code, birthdate and gender will result in an 81% chance of uniquely identifying an individual.
   3. Even a user's email address (like tomj@microsoft.com) can provide a significant amount of User Private Information.

Solution

• A new Identity Model is proposed to give designers and developers guidance on a secure way to think about User Private Information.
• The entirety of the user experience is a rendering by the User Agent of the processes that actually happen on the internet A typical User Agent is a browser for which the User Object is a collection of cookies placed on the user's device for later authentication processes.
• The OpenID Connect protocol is one example of a means to completely separate the authentication process from the release of user private information.
• Clearly the Identifier or Attribute provider is in possession of User Private Information and needs to be trusted to keep that information secure.
• A means must be provided by a relying party to hold user information securely in their servers as a User Object with minimal User Private Information.
• Criteria are proposed for ensuring that users have the ability to:
  • Authenticate themselves for access to the User Object at the relying party (or the IAPs for that matter.)
  • Effectively manage the information in the User Object about them
• Next Steps
  • Determine how to enable trust between the RP and various IAPs.
  • Determine what data needs protection and user control (for example is user public data also covered?)
  • Create a description of the structure document listed above, perhaps like the user consent document currently under development at Kantara.
• A simplified version of the identify model flows is shown below with the three broad categories of entity. The separation of the Authorization from Identity and Attribute Providers ensures that identity tokens are never exposed to the unprotected internet. All three providers could be co-located in some cases. Any digital entity can, and probably will, have some sort of User Object. The relationships among the user objects on the provider side can get complex as is describe in the full model. For more detail see the Identity Model.

References

• An alternate mode is the Classification of Everyday Living completed 2018-06-26 which defines Behaviors and Identifiers in the same way but requires the recording of every event where behaviors are collected. It does not differentiate where data might be stored as in the model, but rather who did the collecting. It also assumes the existence of a "ConsumerID" that can be used by multiple parties, which does not appear to be particularly privacy-preserving. This model allows for diversity of Identifiers. Still it would be possible for an implementation to use both this model and the COEL model at the same time.