Date: Thu, 28 Mar 2024 16:21:45 +0000 (UTC) Message-ID: <1564899645.6643.1711642905321@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6642_1068348590.1711642905319" ------=_Part_6642_1068348590.1711642905319 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In the InCommon identity and access management syste= m, a primary identity is a tuple:
primary identity :=3D (email, phone, firstname, lastname)
A primary identity is associated with a primary role:
For example, we think of a Site Administrator as a person possessing= a verified primary identity. In other words, a Site Administrator= is a role associated with a verified primary identity in the system. = Likewise an InCommon Executive has a verified primary identity, although th= e verification process may not be the same as the verification process for = Site Administrators.
The InCommon Executive identifies the Site Administrators and Registrati= on Authority Officers for the organization. In so doing, the Executive prov= isions primary identities into the system. Initially, a primary identity is= unverified. To become an official Site Administrator or Registration Autho= rity Officer for the organization, that person must verify their identity.<= /p>
Identity verification is a basic operation whose objective is to bind th= e email and phone of a primary identity to a single person. Thus the operat= ion is called Iden= tity Verification:
When first provisioned, a primary identity is unverified. A person with = an unverified primary identity has no privileges in the system. In particul= ar, an individual may not be credentialed until their identity is verified.= In fact, identity verification and credentialing occur in sequence, that i= s, identity verification is a prerequisite for credentialing.
A person may verify their identity many times throughout the lifecycle o= f that identity in the system. In fact, the system may enforce periodic or = ad hoc re-verification of a primary identity subject to policy. Every verif= ication event is recorded in the system for auditing purposes.
By definition, a credential binds an identity to a token used b= y a person to authenticate to a relying party (RP). Here the RP is a SAML s= ervice provider (SP) and the token is a SAML SSO token. How the person obta= ins the SAML token in the first place is a separate topic.
The SAML token asserts a federated identity for the bearer of t= he token. If the SAML token contains an email address, the federated identi= ty may be linked to a verified identity in the system. In that case, SAML W= eb Browser SSO gives rise to a federated credential for the user. = Assuming the SAML token is transmitted securely to the SP, the strength of = the authentication event asserted in the token determines the strength of t= he federated credential, that is, the strength of the binding between the f= ederated identity and the verified identity. Thus the strength of the authe= ntication event asserted in the token is of paramount importance to the SP.=