Subject ID - Revision history

Tom at 01:11, 17 November 2020

2020-11-17T01:11:00Z

Tom: /* Solutions */

2019-05-10T17:07:50Z

‎Solutions

Tom: /* Context */

2019-05-10T17:05:16Z

‎Context

Tom: /* Solutions */

2019-05-07T21:51:08Z

‎Solutions

Tom: /* Other Definitions */

2019-05-07T21:49:09Z

‎Other Definitions

Tom: /* Other Definitions */

2019-05-07T21:48:38Z

‎Other Definitions

Tom at 21:48, 7 May 2019

2019-05-07T21:48:11Z

Tom: /* Other Definitions */

2019-05-07T21:47:22Z

‎Other Definitions

Tom at 21:45, 7 May 2019

2019-05-07T21:45:08Z

Tom: /* Problems */

2019-05-07T21:43:33Z

‎Problems

@@ Line 3: / Line 3: @@
 ==Context==
+* This is a subset of the larger topic [[Subject Identifier]] which looks at the Identifier in all of the locations where it might be discovered and defines types of Identifier.
 * Some providers will reuse [[Subject ID]]s once a connection to a real user has been broken for some specified period of time. Email addresses, in particular, typically have this characteristic. An implementation that was compliant with [[OpenID Connect]] would not reuse [[Subject ID]]s.
 * There is a draft RFC on [[Subject ID]]s for use in [[Security Event Token]]s [https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers Subject Identifiers for Security Event Tokens].

@@ Line 12: / Line 12: @@
 ==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 [[Identifier]]s 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 at any time.
+* 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===

@@ Line 4: / Line 4: @@
 ==Context==
-* Some providers will reuse [[Subject ID]]s once a connection to a real user has been broken for some specified period of time. Email addresses, in particular, typically have this characteristic. A fully compliant implementation would not reuse [[Subject ID]]s.
+* Some providers will reuse [[Subject ID]]s once a connection to a real user has been broken for some specified period of time. Email addresses, in particular, typically have this characteristic. An implementation that was compliant with [[OpenID Connect]] would not reuse [[Subject ID]]s.
 * There is a draft RFC on [[Subject ID]]s for use in [[Security Event Token]]s [https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers Subject Identifiers for Security Event Tokens].

@@ Line 12: / Line 12: @@
 ==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 [[Identifier]]s are also subject to change at the [[user]]'s discretion and can be diverted by a determined attacker.
 ===Other Definitions===

@@ Line 16: / Line 16: @@
 *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]]   <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.  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 [[Security Event Token]]   <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>
 ==References==

@@ Line 8: / Line 8: @@
 ==Problems==
+* While the [[Subject ID]] (sub) is often taken to be a persistent [[Identifier]] for a real-world entity, there are several example of its use as and [[Ephemeral]] ID.
 ==Solutions==