Page History

...

Technical implementation of identity assurance requires system changes from InCommon Operations, IdPs, and SPs. There are many different scenarios and choices.

InCommon metadata management

InCommon Operations will add IAQs to the published metadata following notification of certification by InCommon management. These will apply to the relevant IdP entries of the certified IdPOs.  Proposed IAQ URIs are:

Silver:  http://id.incommon.org/assurance/silver

Bronze:  http://id.incommon.org/assurance/bronze

There will likely be a need for non-production IAQs for use in interop testing, probably with test instances of metadata.  Proposed test IAQs:

Silver:  http://id.incommon.org/assurance/silver-test

Bronze:  http://id.incommon.org/assurance/bronze-test

Note that all of the above URIs will resolve to real pages at some point.

SP behavior

Ideally SPs will initiate the assurance flow by including the desired IAQ in the SAML AuthnRequest element.

• What matching rules are recommended, or acceptable?
• Some SPs may not be able to use the AuthnRequest mechanism due to software or other limitations.  Are they out of luck?
• How is this configured using the Shib SP?  The simpleSAMLphp SP?
• Boarding process:  Since an IAQ in metadata makes a statement about certification (not live service), how does an SP determine that an IdP supports assurance operationally (ala attribute support)? One approach is to include <saml:Attribute> elements in IdP metadata. Other approaches?

SPs will receive IAQs (either in response to a specific request, or sent unsolicited) in assertions from IdPs.  SPs should use metadata for the relevant IdPs to check that they are certified to assert the IAQs they're asserting.

• Does the Shib (or simpleSAMLphp) SP software support the metadata check?

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.

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

• What matching rules are supported?
• Is it possible and/or desirable for the IdP to return multiple IAQs? No, not using the AuthnContext element.
• How does the Shib (or SSP) IdP interact with local IdM?  Is a custom login handler required?

SPs may not put IAQs in AuthnRequests but still want to receive IAQs from IdPs.

This page (and its child pages) capture lessons learned, recommended practices, and outstanding issues regarding the technical aspects of identity assurance.

SAML V2.0 Support for Assurance

SAML's support for identity assurance is embodied in a concept called "Authentication Context". The context of an authentication event is designed to capture both technical and procedural elements that factor into the "confidence" expressed by the identity provider in the event. In terms of assurance, this maps to the concepts of technical strength and identity proofing strength that make up an assurance profile.

Every authentication statement issued by an IdP contains an <saml:AuthnContext> element that expresses the context of the authentication event. There are a variety of syntaxes supported, but the most common one is to define a "class" of authentication contexts that all share essential characteristics that are of interest to a relying party. These classes are mapped to URI constants that are expressed in an element called <saml:AuthnContextClassRef>, of which a single value can be expressed by the IdP in response to an authentication request.

In addition, SAML V2.0 SPs have the capability to include simple or complex matching requirements in their authentication requests that influence the Authentication Context supplied by the IdP. The intent is to allow IdPs that support varying levels of assurance to honor requests based on the requirements of the SP and not a one-size-fits-all policy. In practice, this approach can be tricky to implement and may depend on customization of one's software deployment.

Thus, we expect assurance deployment to be gradual, and we will continue to evolve documentation to reflect what we learn. We also encourage deployers to talk to their software suppliers about the support (or lack thereof) of these features.

InCommon Practices

See: InCommon Practices - Certification and Metadata

SP Behavior

See: Assurance - Service Provider Behavior.

IdP Behavior

See: Assurance - Identity Provider Behavior.

References

• SAML V2.0 Core
• SAML V2.0 Metadata Extension for Entity Attributes
• SAML V2.0 Identity Assurance Profiles

...