Technical implementation of assurance requires system changes from InCommon Operations, IdPs, and SPs. There are many different scenarios and choices.
Participation in the InCommon Identity Assurance Program requires the use of SAML V2.0 Web Browser SSO. IdP and SP operators should plan for an upgrade path to SAML V2.0.
InCommon Operations will add identity assurance qualifiers (IAQs) to published metadata following notification of certification by InCommon management. IAQs will be added to the appropriate IdP entity descriptor of the certified IdP operator (IdPO).
Proposed IAQ URIs are:
There will likely be a need for non-production IAQs for use in interoperability testing, probably with test instances of metadata:
Note that all of the above URIs will resolve to actual web pages at some point.
The following extension element will be added to the IdP's entity descriptor in metadata:
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"> <saml:AttributeValue>http://id.incommon.org/assurance/silver</saml:AttributeValue> <saml:AttributeValue>http://id.incommon.org/assurance/bronze</saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes>
<mdattr:EntityAttributes> element and the name of the
<saml:Attribute> element are defined by relevant OASIS specifications.
Ideally SPs will initiate the assurance flow by including the desired IAQ in the SAML AuthnRequest element.
SPs will receive IAQs (either in response to a specific request, or sent unsolicited) in assertions from IdPs. SPs should use metadata to check that the IdP is authorized to assert the IAQs being asserting.
SPs will rely on local policy to decide how to handle incoming IAQs. For example if the SP requires InCommon Bronze but receives InCommon Silver, that should be acceptable.
<saml:Attribute>elements in IdP metadata. Other approaches?
Ideally IdPs will receive a desired IAQ from an SP in an AuthnRequest to initiate the process. The IdP compares the requested IAQ to its matching rule and interacts with the local IdM system to determine if the current user meets the requirements. If so, the appropriate IAQ is returned in the AuthnContext element in the assertion.