Difference between revisions of "Subject Identifier"

Latest revision as of 16:32, 19 November 2020

Full Title or Meme

A Subject Identifier is an abstract definition of an Identifier that only identifies an entity that has private data or access to private resources on the web.

Context

• This is a superset of the topic Subject ID which looks at a digital Identifier associated with some real-world Entity that has established an interchange on the internet by means of a User Agent.
• Some uses of Subject Identifier are to create alternative Identifiers or to link an old Identifier into a new one, or to act as a Also Known As. (aka) identifier.
• There is a draft RFC on Subject IDs for use in Security Event Tokens Subject Identifiers for Security Event Tokens.

Problems

• While the Subject ID (sub) is often taken to be a persistent Identifier for a real-world entity, there are several examples of its use as and Ephemeral ID.

Solutions

• Users are often asked to use their email address or cell phone number as a local user name since the email address and phone number with country code (+1 in North America) are known to be a URI and hence unique in that context. Reuse of email and phone numbers could be an issue. Note that these Identifiers are also subject to change at the user's discretion and can be diverted by a determined attacker.
• This wiki uses Subject ID primarily as identifying the subject of a claim about a real-world entity. It is subject to revocation by the user or the claim issuer at any time.

Other Definitions

• From JWT^[1]

  The "sub" (subject) claim identifies the principal that is the subject of the JWT. The Claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.

• From OpenID Connect
  • From OpenID Connect Core Spec 1.0

    sub = Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case sensitive string.

  • From OpenID Connect for Identity Assurance 1.0 (also uses sub from OIDC)

    Mark said they had defined an aka, but I couldn't find it.

• [https://docs.google.com/presentation/d/1rOIKWSrL8acz-rl8PRHmPvS5f6fOl7-tQwByT6O595A/edit#slide=id.p
• OWL Web Ontology Language Reference W3C Recommendation 2004-02-10 Individual identity = Many languages have a so-called "unique names" assumption: different names refer to different things in the world. On the web, such an assumption is not possible. For example, the same person could be referred to in many different ways (i.e. with different URI references). For this reason OWL does not make this assumption. Unless an explicit statement is being made that two URI references refer to the same or to different individuals, OWL tools should in principle assume either situation is possible. OWL provides three constructs for stating facts about the identity of individuals:
  • owl:sameAs is used to state that two URI references refer to the same individual.
  • owl:differentFrom is used to state that two URI references refer to different individuals
  • owl:AllDifferent provides an idiom for stating that a list of individuals are all different.
• From Security Event Token (This is tentatively the same list for GNAP)

  A Subject Identifier Type is a light-weight schema that describes a set of claims that identifies a subject. Every Subject Identifier Type MUST have a unique name registered in the IANA "Security Event Subject Identifier Types" registry established by Section 6.1 of Security Event Token. A Subject Identifier Type MAY describe more claims than are strictly necessary to identify a subject, and MAY describe conditions under which those claims are required, optional, or prohibited.

       "subject": {
         "subject_type": "iss-sub",
         "iss": "https://idp.example.com/",
         "sub": "7375626A656374"
       },

The Special case of DIDs

Frankly, no one seems to agree what a DID actually is. Note in particular that the current effort is to eliminate the type on the DID so that it would not even be possible to determine if the subject of the DID qualified for GDPR protections!

• From Verified Claims (yeah- that's weird. This seems to say that identify proofing could not be a VC?) The process of binding a DID to something in the real world, such as a person or a company, for example with credentials with the same subject as that DID, is out of scope for this specification.

I copied the following from the current rant at: https://github.com/w3c/did-core/pull/460

• A DID is a URI as defined by RFC 3986.
• The first line of RFC 3986 is: "A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource."
• Therefore a DID identifies an abstract or physical resource.
• In this specification, the resource identified by a DID is called a DID subject.

You can make all kinds of arguments about whether a particular DID produced by a particular DID method is anonymous, pseudonymous, or verinymous. But regardless, it still identifies the DID subject. That's what identifiers do. Furthermore, if a DID identifies a natural person in any way that can ever be associated with that person—no matter how anonymous or pseudonymous it starts out or what mechanism is used to make that association (including proof of control)—then that DID is personal data under GDPR. (not sure how this is ever determined.)

The following come from DID WG Topic Call on Equivalence Properties 2020-11-19 -- note this is a pull request, but it seems to need significant change before it is voted on.

It was pointed out that any equivalence property becomes another attack point. Communicating this information through another channel also introduces security risks, that you don’t have if it’s in a DID document.

the use case is to hand DIDs to a user before the DID is registered, so that later it can be resolved. There may be a simpler alternative, but none was accepted.

The first equivalence property is “sameAs”.. A DID method can define different forms of a DID that are logically equivalent.

• One example is if the DID changes before registration and after registration
• In this case, the DID method may specify multiple DIDs that are logically equivalent
• Each sameAs DID must be within the same method
• DID method must guarantee that DIDs are logically equivalent
• A relying party must retain the DIDs, e.g. in a database

Ivan Herman: I would prefer not to use the “sameAs” term. Either this is owl:sameAs and you say it, or it’s something different

• Resolution #1: sameAs/equivalentDIDs can only contain entries from the same did method as the the did document id.
• Resolution #2: The two properties we are defining for equivalence are: equivalentId and canonicalId.

References

1. Synonyms for a Subject ID include User Name, display name, gamertag, nom de guerre, Pseudonym, URI or (on Facebook) Name subject to arbitrary termination.
2. Anonym is not used in the context of identity as it does not provide one. It may be used as the condition (Anonymous) of a user prior to accepting (1) a cookie, (2) a fixed IP address, (3) an HTTPS connection or (4) a request for an Identifier.
3. ↑ M. Jones J. Bradley N. Sakimura, JSON Web Token (JWT). (2016-02) IETF https://tools.ietf.org/html/rfc7519