Date: Thu, 28 Mar 2024 21:30:35 +0000 (UTC)
Message-ID: <1963284148.7041.1711661435495@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_7040_2014978469.1711661435494"
------=_Part_7040_2014978469.1711661435494
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
If InCommon chooses to adopt the IdPoLR Working Group's recommen=
dation to help make available an IdPoLR service as soon as possible, then U=
nitedId.org would be a strong candidate. That claim is based on the followi=
ng evaluation of UnitedId against the requirements defined in the WG's fina=
l report.
UnitedId meets the following MUST requirements today:=
p>
- Support for user self-registration (but see first bullet under 'some de=
v. work needed' below)
- Once a user has authenticated an SSO session is established at the IdP<=
/li>
- Ability to assign ePPN (these are non-reassignable)
- Accepts SP requests for authentication contexts via the standard SAML2 =
Authentication Request Protocol
- Support for Tech Basics for IdPs
- Conforms to saml2int
- No commercial interest in the use of user data (by organizational princ=
iple, backed by support of Code of Conduct)
- Available to users throughout the world
By joining InCommon and taking a set of procedural steps, United=
Id could also meet the following MUST Requirements
- IdP must support R&S
- Support for ECP (already on UnitedId roadmap under near-term goals)
- InCommon and UnitedId would work together to define approaches to servi=
ce sustainability, but the first goal is to get an initial IdPoLR in servic=
e and in use
- Self assertion of bronze
- IdP must be available globally to any R&S tagged SP (both InCommon =
and Refeds R&S for now)
Some development work would be needed to meet the remaining MUST=
Requirement
- User registration incorporated into sign-in flow, so new user is not st=
randed at IdP. NOTE: In case user is a first-time registrant at Unite=
dId, the second factor issuance/registration process will not be instantane=
ous. In such cases, an appropriate SAML error message is returned to the SP=
so that the user is not stranded between IdP and SP, but is returned to th=
e SP where the error can be handled gracefully.
UnitedId also meets the following desired conditions:=
p>
- Support for user consent
- Accepts non-ASCII characters in user-entered data
- Supports multi-factor authN (MFA)
- No cost for users* *if they have a smart =
phone, or SP subsidizes other 2nd factor
Steps Entailed if Recommendation is Accepted=
h5>
If InCommon endorses the primary recommendation and chooses to move ahea=
d toward a UnitedId-based IdP of Last Resort, the next steps would include =
the following:
- Open discussions with UnitedId to come up with a mutually agreed-upon s=
et of terms and conditions to launch an IdPoLR and maintain it for a stated=
period of time (do this in consultation with key R&S SP stakeholders)<=
/li>
- Arrange for UnitedId to become a member of InCommon
- Have this IdPoLR designated as supporting R&S (both InCommon and Re=
feds R&S definitions)
- Authorize this IdPoLR to assert compliance with InCommon Bronze level o=
f assurance
- Develop a communication plan to inform R&S SPs (and users) of the a=
vailability and purposes of the service
------=_Part_7040_2014978469.1711661435494--