Skip to content
Go to file
1 contributor

Users who have contributed to this file

38 lines (19 sloc) 2.58 KB

Future-Proofed and Federation Ready Enterprise Identifiers

All the proposed schemes for ‘’enterprise ids” that I’ve heard so far can also work in SAML federation and OIDC contexts at the cost of a couple additional syntax and semantic constraints. I will write up the details and add a link to these notes when it’s ready"

subject-id: {unique id} '@' {scope}


MUST BE bound to the XML Schema xsd:string data type [XMLSCHEMA-2].

The value consists of two substrings (termed a “unique ID” and a “scope” in the remainder of this definition) separated by an @ symbol (ASCII 64) as an inline delimiter.

The unique ID consists of 1 to 127 ASCII characters, each of which is either an alphanumeric ASCII character, an equals sign (ASCII 61), or a hyphen (ASCII 45). The first character MUST be alphanumeric.

The scope consists of 1 to 127 ASCII characters, each of which is either an alphanumeric ASCII character, a hyphen (ASCII 45), or a period (ASCII 46). The first character MUST be alphanumeric.

Note that subject-ids must be matched in a case-INsensitive manner.

The scope deliberately resembles, and often is, a DNS domain name, but is drawn from a more limited character set due to case folding considerations, and no attempt is made to limit the allowable grammar to legal domain names (e.g., it allows consecutive periods).


A value MUST NOT be assigned to more than a single subject over its lifetime of use under any circumstances

Relying parties should not treat this identifier as an email address for the subject as it is unlikely (though not precluded) for it to be valid for that purpose.

The unique ID should not change as a result of a change to any other data associated with the subject (e.g., name, email address, age, organizational role) This essentially forbids the use of name-based identifiers since it is impossible to guarantee that name-based identifiers will never change.

A given value MUST identify the same subject regardless of the context of use or the relying parties to which the attribute is given. It is therefore to be assumed by relying parties that receive a given value that the same subject has been identified.

A single subject MAY be identified simultaneously by a single asserting party by multiple values, but this should be minimized to the extent possible.


A given subject MUST be identified with a different, though consistent, unique ID for each relying party

You can’t perform that action at this time.