Page History

...

...

Metadata management

InCommon Operations will add identity assurance qualifiers (IAQs) to the published metadata following notification of certification by InCommon management. These IAQs will apply be applied to the relevant IdP entries entity descriptors of the certified IdP operators (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 interoperability 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 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.

SP behavior

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

...

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.  How is an SP supposed to "know" this?  Is there a role for InC 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.

...

• 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