DRAFT

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

Proposed IAQ URIs are:

Silverhttp://id.incommon.org/assurance/silver
Bronzehttp://id.incommon.org/assurance/bronze

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

Silverhttp://id.incommon.org/assurance/silver-test
Bronzehttp://id.incommon.org/assurance/bronze-test

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">
    <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>
</md:Extensions>

The <mdattr:EntityAttributes> element and the name of the <saml:Attribute> element are defined by the OASIS SAML V2.0 Metadata Extension for Entity Attributes and the OASIS SAML V2.0 Identity Assurance Profiles, respectively.

Issues

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

Issues

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.

Issues

References