Assurance Technical Implementation Issues

DRAFT

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

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:

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 interoperability testing, probably with test instances of metadata:

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 actual web pages at some point.

IAQs in metadata

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>

The <mdattr:EntityAttributes> element and the name of the <saml:Attribute> element are defined by relevant OASIS specifications.

Issues

• The entity attribute and/or the IAQ has to be dated or versioned to indicate exactly what IAP is referred to.

SP behavior

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.

Issues

• Some SPs may not be able to use the AuthnRequest mechanism due to software or other limitations. Are they simply out of luck?
• How is the AuthnRequest 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?
• Does the Shib SP software support the metadata check? Does the simpleSAMLphp SP?
• What matching rules are recommended, or acceptable?
• How is an SP supposed to "know" that Silver is acceptable in lieu of Bronze? Is there a role for InCommon to provide "advice"?

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

• What matching rules are supported?
• If the SP requests Bronze, is it allowable for the IdP return Silver? How does the IdP "know" the mapping? Is there a role for InC to provide "advice"?
• Is it possible and/or desirable for the IdP to return multiple IAQs? No, not using the AuthnContext element.
• How does the Shib IdP interact with local IdM? Is a custom login handler required? Same question for simpleSAMLphp.
• If an SP does not assert an IAQ in an AuthnRequest and the current user meets the requirements for one or more IAQs, should the IdP assert the IAQ(s).
• Can the Shib (or SSP) IdP be configured to send IAQs without being requested?
• If so, what are the appropriate policy knobs (per-SP, per-user, whatever)?

References

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