Technical implementation of identity assurance requires system changes from InCommon Operations, IdPs, and SPs. This page captures lessons learned, recommended practices, and outstanding issues regarding the technical aspects of identity assurance.

Participation in the InCommon Identity Assurance Program requires the use of SAML V2.0 Web Browser SSO. IdP and SP operators should plan to upgrade to SAML V2.0 as soon as possible.

Metadata management

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).

Participants are not obligated to enforce policies or otherwise make use of these qualifiers, but they are provided so that supporting software may be configured to make use of the information when processing assertions containing assurance qualifiers.

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.

IAQs in metadata

The following extension is the immediate child element of the IdP's <md:EntityEescriptor> element in metadata:

<md:Extensions xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">

The <mdattr:EntityAttributes> element and the name of the SAML Attribute (urn:oasis:names:tc:SAML:attribute:assurance-certification) are defined by the OASIS specification entitled SAML V2.0 Metadata Extension for Entity Attributes and the OASIS SAML V2.0 Identity Assurance Profiles, respectively.

A complete, working metadata sample is attached to this wiki topic. To schema validate this sample metadata, you can use XmlSecTool:

xmlsectool.sh --validateSchema \
    --schemaDirectory schema-files --inFile incommon-idp-metadata.xml

For convenience, we provide a set of (suitably modified) schema files that permit offline schema validation.

SP behavior

Ideally SPs that require a particular assurance level 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 is probably acceptable.

SP Policy Use Cases


IdP behavior

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 rules 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; if not, an error is returned.