Subject Identifier - Revision history

Tom: /* Other Definitions */

2020-11-20T00:32:39Z

‎Other Definitions

Tom: /* Other Definitions */

2020-11-20T00:20:18Z

‎Other Definitions

Tom: /* Other Definitions */

2020-11-20T00:18:51Z

‎Other Definitions

Tom: /* The Special case of DIDs */

2020-11-19T23:56:05Z

‎The Special case of DIDs

Tom: /* The Special case of DIDs */

2020-11-19T23:54:55Z

‎The Special case of DIDs

Tom: /* Other Definitions */

2020-11-19T23:19:32Z

‎Other Definitions

Tom: /* Other Definitions */

2020-11-19T23:18:38Z

‎Other Definitions

Tom: /* The Special case of DIDs */

2020-11-17T06:49:20Z

‎The Special case of DIDs

Tom: /* The Special case of DIDs */

2020-11-17T06:46:52Z

‎The Special case of DIDs

Tom: /* Other Definitions */

2020-11-17T06:46:19Z

‎Other Definitions

@@ Line 17: / Line 17: @@
 *From JWT<ref>M. Jones J. Bradley N. Sakimura, ''JSON Web Token (JWT).'' (2016-02) IETF https://tools.ietf.org/html/rfc7519</ref> <blockquote>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.</blockquote>
-*From [[Security Event Token]]  (This is tentatively the same list for GNAP) <blockquote> 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.</blockquote>
 * From [[OpenID Connect]]
 ** From OpenID Connect Core Spec 1.0<blockquote>  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.</blockquote>
@@ Line 26: / Line 26: @@
 ** 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.
 ===The Special case of DIDs===

@@ Line 20: / Line 20: @@
 * From [[OpenID Connect]]
 ** From OpenID Connect Core Spec 1.0<blockquote>  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.</blockquote>
-** From OpenID Connect for Identity Assurance 1.0 (also uses sub from OIDC)<blockquote> Mark said they had one, but I couldn't find it.</blockquote>
+** From OpenID Connect for Identity Assurance 1.0 (also uses sub from OIDC)<blockquote> Mark said they had defined an aka, but I couldn't find it.</blockquote>
 * [https://docs.google.com/presentation/d/1rOIKWSrL8acz-rl8PRHmPvS5f6fOl7-tQwByT6O595A/edit#slide=id.p
 * [https://www.w3.org/TR/owl-ref/#IndividualIdentity 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:

@@ Line 19: / Line 19: @@
 *From [[Security Event Token]]  (This is tentatively the same list for GNAP) <blockquote> 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.</blockquote>
 * From [[OpenID Connect]]
-** From OpenID Connect Core Spec 1.0<blockquote> </blockquote>
+** From OpenID Connect Core Spec 1.0<blockquote>  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.</blockquote>
 ** From OpenID Connect for Identity Assurance 1.0 (also uses sub from OIDC)<blockquote> Mark said they had one, but I couldn't find it.</blockquote>
 * [https://docs.google.com/presentation/d/1rOIKWSrL8acz-rl8PRHmPvS5f6fOl7-tQwByT6O595A/edit#slide=id.p

@@ Line 50: / Line 50: @@
 * DID method must guarantee that DIDs are logically equivalent
 * A relying party must retain the DIDs, e.g. in a database
 * 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==

@@ Line 36: / Line 36: @@
 * 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.
+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.)
-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 [https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-11-19-did-topic 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.
 ==References==

@@ Line 24: / Line 24: @@
 ===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!
-* [https://w3c.github.io/did-core/#authentication-and-verifiable-claims: From Verified Claims] (yeah- that's weird) 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.
+* [https://w3c.github.io/did-core/#authentication-and-verifiable-claims: 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.