Identity Model - Revision history

Tom: /* Identifier Provider View */

2025-10-26T18:23:14Z

‎Identifier Provider View

Tom: /* History */

2024-09-01T20:58:09Z

‎History

Tom: /* Architecture to implement this Model */

2024-02-14T01:14:59Z

‎Architecture to implement this Model

Tom: /* Takeaways and Future Work */

2024-02-14T01:13:48Z

‎Takeaways and Future Work

Tom: /* General References */

2022-05-21T13:30:09Z

‎General References

Tom: /* User's View */

2021-12-13T22:19:14Z

‎User's View

Tom: /* Identity from the Identifier Providers Perspective */

2021-02-14T01:21:01Z

‎Identity from the Identifier Providers Perspective

Tom: /* Identity from the Identity Providers Perspective */

2021-02-14T01:20:34Z

‎Identity from the Identity Providers Perspective

Tom: /* The User as Subject */

2020-03-09T19:20:58Z

‎The User as Subject

Tom: /* Identity Taxonomy */

2019-08-27T22:27:19Z

‎Identity Taxonomy

@@ Line 142: / Line 142: @@
 NIST documentation allocates some of the Identifier Provider functionality to the Registration Authority or RA. Others have called this function a namespace provider.
-In the [http://openid.net/connect/ OpenID Connect protocol], the IdP sends a packet to the RP with an identifier of the user that is not their email address. While not specifically required by the specification, a privacy conscious IdP would use a different id for the user at every single RP. In [http://openid.net/connect/ OpenID] terms an identifier  is acquired by Authentication protocol which is strictly constrained to occur between the OpenID provider (OP or IdP) and the user.
+In the [http://openid.net/connect/ OpenID Connect protocol], the IdP sends a packet to the RP with an identifier of the user that is not their email address. While not specifically required by the specification, a privacy-aware IdP would use a different id for the user at every single RP. In [http://openid.net/connect/ OpenID] terms an identifier  is acquired by Authentication protocol which is strictly constrained to occur between the OpenID provider (OP or IdP) and the user.
 ===Secure Token Service View===

@@ Line 6: / Line 6: @@
 Identity is core to any object that we want to access, change or even discuss. Before we can even describe some thing, we need to be able to name that thing. The naming of objects has been a concern ever since the book of Genesis was written. One problem with the name of a object, is that most objects that we see in our everyday life are changing even as we try to describe them. Even the ancient Greek philosopher [https://en.m.wikipedia.org/wiki/Heraclitus Heraclitus] understood that the name of a river was ephemeral as you can never step twice into the same river as the contents of the river are constantly changing. The same statement can be made about any human being or any organization. But the reality is that all relationships are based around the idea of identity, as diffuse as that idea might be. Before we can start to make statements about an identity, it is best to create some model that will help us establish a context where we can intelligently discuss identity. Existing identity models have been organized around the identifier that a user has registered at an Identity Provider (IdP). This has lead to a back-lash against the use of the term identity in the technical community.
-Note that other philosophers have established the [https://en.wikipedia.org/wiki/Law_of_identity Law of Identity] to be a naming of one particular thing. In logic, the law of identity states that each thing is identical with itself. By this it is meant that each thing (be it a universal or a particular) is composed of its own unique set of characteristic qualities or features, which the ancient Greeks called its essence. It is the first of the three classical laws of thought. For this model the essence of an identity will be the identifiers, attributes, behaviors and inferences collected about that thing, and how to accommodate that data as it changes over time.
+Note that other philosophers have established the [https://en.wikipedia.org/wiki/Law_of_identity Law of Identity] to be a naming of one particular thing. In logic, the law of identity states that each thing is identical with itself. By this it is meant that each thing (be it a universal or a particular) is composed of its own unique set of characteristic qualities or features, which the ancient Greeks called its essence. It is the first of the three classical [[Laws of Thought]]. For this model the essence of an identity will be the identifiers, attributes, behaviors and inferences collected about that thing, and how to accommodate that data as it changes over time.
 For all the nice fuzzy sentiment about identity, it was created and maintained entirely for the benefit of the state. The side benefit for users was the rights that it gave them to state generated benefits. What rights people did have was the right to assign a new baby’s given name. The baby had no right to establish anything. When a child reached its majority, it was allowed to petition to change the legal name to be used in legal documents.

@@ Line 168: / Line 168: @@
 [[File:IdentityModelFull.png]]
-Note that since third party cookies are no longer support, this flow will only work if the authz grant, the token issuance and the user resource are all from the same origin. For more detail see the wiki page [[Origin Access Control]].
+Note that since third party cookies are no longer supported by browsers since 2023, this flow will only work if the authz grant, the token issuance and the user resource are all from the same origin. For more detail see the wiki page [[Origin Access Control]].
 ==Takeaways and Future Work==

← Older revision		Revision as of 01:13, 14 February 2024
Line 167:		Line 167:

	[[File:IdentityModelFull.png]]		[[File:IdentityModelFull.png]]
		+
		+	Note that since third party cookies are no longer support, this flow will only work if the authz grant, the token issuance and the user resource are all from the same origin. For more detail see the wiki page [[Origin Access Control]].

	==Takeaways and Future Work==		==Takeaways and Future Work==

@@ Line 254: / Line 254: @@
 Phil Windley has create [http://www.windley.com/archives/2019/08/life-like_identity_why_the_internet_needs_an_identity_metasystem.shtml a model based on DIDs and Verified Credential] that is very ambitious, but without sufficient detail to make a deployment feasible.
 ===General References===
-One of the [http://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.8054.pdf NIST NSTIC Pilots] recipient was [http://www.aamva.org/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=4563&libID=4540 The American Association of Motor Vehicle Administrators (AAMVA)] and included the [http://www.aamva.org/uploadedFiles/MainSite/Content/EventsEducation/Event_Materials/2013/2013_Annual_International_Conference/Goodbye%20Usernames%20and%20Passwords%20-%20Farnsworth.pdf Commonwealth of Virginia DMV - Department of Motor Vehicles]. Like most DMVs the one in Virginia was blocked from offering identity or attribute services except to other governmental organizations. on [https://lis.virginia.gov/cgi-bin/legp604.exe?171+ful+CHAP0697 March 24, 2017 Virginia passed a regulation] which expands the areas where the DMV id can be used. Virginia has a [https://www.dmv.virginia.gov/onlineServices/#index.html My DMV] sign in ID that can be used for the widest variety of governmental service of any state in the union. This regulation mandates a $10 per year fee for the electronic credential, which could hinder the continued use of this by many of the citizens of Virginia who could most benefit from the capability, not because of the cost, but because of the inconvenience. A [https://vi.virginiainteractive.org/vi/documents/dmv-information_use_app.pdf standard form] is already available to request [https://vi.virginiainteractive.org/vi/get-started.shtml access to DMV data]. Virginia also offers ID cards that are the equal to the driver's license for access to governmental spaces and a veteran's card, which is not.
+One of the [http://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.8054.pdf NIST NSTIC Pilots] recipient was [http://www.aamva.org/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=4563&libID=4540 The American Association of Motor Vehicle Administrators (AAMVA)] and included the [http://www.aamva.org/uploadedFiles/MainSite/Content/EventsEducation/Event_Materials/2013/2013_Annual_International_Conference/Goodbye%20Usernames%20and%20Passwords%20-%20Farnsworth.pdf Commonwealth of Virginia DMV - Department of Motor Vehicles]. Like most DMVs the one in Virginia was blocked from offering identity or attribute services except to other governmental organizations. on [https://lis.virginia.gov/cgi-bin/legp604.exe?171+ful+CHAP0697 March 24, 2017 Virginia passed a regulation] which expands the areas where the DMV id can be used. Virginia has a [https://www.dmv.virginia.gov/onlineServices/#index.html My DMV] sign in ID that can be used for the widest variety of governmental service of any state in the union. This regulation mandates a $10 per year fee for the electronic credential, which could hinder the continued use of this by many of the citizens of Virginia who could most benefit from the capability, not because of the cost, but because of the [[Inconvenience]]. A [https://vi.virginiainteractive.org/vi/documents/dmv-information_use_app.pdf standard form] is already available to request [https://vi.virginiainteractive.org/vi/get-started.shtml access to DMV data]. Virginia also offers ID cards that are the equal to the driver's license for access to governmental spaces and a veteran's card, which is not.
 [[Category:Glossary]]
 [[Category:User Experience]]
 [[Category:Identity]]

@@ Line 115: / Line 115: @@
 ===User's View===
-The [http://idesg-rp.azurewebsites.net/Account/Login best practice example] web page shows the types of IdP that a user should be able to pick at a relying party. The user is trying to find the least intrusive method to gain access to the relying party. To get access the user will typically need to provide some attributes that are able to assure the RP that the access is authorized. To prevent spoofing, the required attributes are tied to some identifier which is, in some sense, tied to something in the real-world. For the purposes of this user-experience model, only human beings are considered although other named identities, including security connection identifiers may be appropriate in other contexts.
+The [http://idesg-rp.azurewebsites.net/Account/Login best practice example] web page shows the types of IdP that a user should be able to pick at a relying party. The user is trying to find the least intrusive method to gain access to the relying party. To get access the user will typically need to provide some attributes that are able to assure the RP that the access is authorized. To prevent [[Identity Spoofing]] , the required attributes are tied to some identifier which is, in some sense, tied to something in the real-world. For the purposes of this user-experience model, only human beings are considered although other named identities, including security connection identifiers may be appropriate in other contexts.
 Traditionally users have acquired a username and password from the web sites where they want to establish a continuing identity. The web sites liked to have control of their users and the user could pick a username that was unique for each web site to prevent linking between web sites. In practice the users always tried to pick a name that they could remember without having to look it up in some list. Name collision at sites prevented anyone with a common name from using the same name on every site. For a better user experience and for access to separate communications channel, web sites began to request the user's email address, which is loosely guaranteed to be unique by the rules of the internet. At this point these web sites became relying parties on email providers which became identifier providers somewhat be default.

@@ Line 33: / Line 33: @@
 The Relying Party provides a collection of resources or assets to users. The RP uses identifiers to collect attributes into a [[User Object]] that allows them to control access to some subset of those resources. Their primary concern is the risk of losing any economic and reputational ownership of those resources. It is very likely that an RP will have more than one identifier in each [[User Object]] with one (the key) used to identify that [[User Object]]. At the very least they have their own identifier for the user and an identifier from any IdP hosting that user's identifier and attributes. Users can authenticate to the [[User Object]] in the computer as a [[Principal]] in that system for the duration of the authentication lifetime, which should be coincident with the interchange lifetime as used by the BFR.
-====Identity from the Identifier Providers Perspective====
+====Identity from the Identifier Provider's Perspective====
 The various Identifier Providers look at the collection of user identifiers and attributes as a resource that helps them to establish a relationship with the users. They typically also offer some service to the user like email or financial services. A prudent IdP will provide an opaque identifier to every user-RP pair as the user identifier with the IdP should be considered to be [[User Private Information]]. This model breaks the Identity functions into 3 providers: Identifier, Authorization and Attribute.

@@ Line 174: / Line 174: @@
 ===The User as Subject===
-As a general rule, the user is a species of carbon-based life identified as a human being. It would seem that all human beings should have an identity, but this is not the case today. Some human beings do not have legal status and some organizations do have legal status. Many web sites are very interested in whether the user is a real human being, and others are interested in the legal status of the user. This model is focused on the user as a human being with a set of attributes and behaviors, an identity. The [https://www.unicef.org/protection/BirthReg10a_rev.pdf United Nations have agreed] that all human beings deserve to have an identity. Most nation's laws assert that only human beings can make legal commitments. That said, no human beings have yet been directly attached to the internet and so we are dependent on user agents to capture the intent of the user and pass that intent onto the relying party. The relying party has two legitimate concerns with the level of assurance for the expressed intent: 1) how strong is the binding between the human being and the message received, and 2) what sort of attestation has been made about the reliability of the device and software user agent in reliably reporting that intent. Both of these issues are addressed in other venues and are not further addressed in this model. Another issue not addressed here is whether the user or user agent is legitimately committing some other legal entity by the transaction. It must be noted that the right to have a digital identifier [https://leveloneproject.org/wp-content/uploads/2015/04/The-Level-One-Project-Guide-Designing-a-New-System-for-Financial-Inclusion1.pdf has been shown empirically] to be at odds with relying parties' desire for strong assurance. In every case possible relying parties should not ask for more user attributes or assurance than is required by law.
+As a general rule, the user is a species of [[Carbon-based Life Form]] identified as a human being. It would seem that all human beings should have an identity, but this is not the case today. Some human beings do not have legal status and some organizations do have legal status. Many web sites are very interested in whether the user is a real human being, and others are interested in the legal status of the user. This model is focused on the user as a human being with a set of attributes and behaviors, an identity. The [https://www.unicef.org/protection/BirthReg10a_rev.pdf United Nations have agreed] that all human beings deserve to have an identity. Most nation's laws assert that only human beings can make legal commitments. That said, no human beings have yet been directly attached to the internet and so we are dependent on user agents to capture the intent of the user and pass that intent onto the relying party. The relying party has two legitimate concerns with the level of assurance for the expressed intent: 1) how strong is the binding between the human being and the message received, and 2) what sort of attestation has been made about the reliability of the device and software user agent in reliably reporting that intent. Both of these issues are addressed in other venues and are not further addressed in this model. Another issue not addressed here is whether the user or user agent is legitimately committing some other legal entity by the transaction. It must be noted that the right to have a digital identifier [https://leveloneproject.org/wp-content/uploads/2015/04/The-Level-One-Project-Guide-Designing-a-New-System-for-Financial-Inclusion1.pdf has been shown empirically] to be at odds with relying parties' desire for strong assurance. In every case possible relying parties should not ask for more user attributes or assurance than is required by law.
 ===The User Object===

@@ Line 112: / Line 112: @@
 * [https://benohead.com/oauth-2-0-openid-connect-explained/ OpenID Connect explained] contains some terms described.
-* [https://backstage.forgerock.com/docs/am/6.5/oidc1-guide/ ForgeRock] has an ever more complete glossary.
+* [https://backstage.forgerock.com/docs/am/6.5/oidc1-guide/ ForgeRock] has an even more complete glossary.
 ===User's View===