Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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:

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 interop testing, probably with test instances of metadata.  Proposed test IAQs:

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

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

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

...

  • 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?  simpleSAML 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)?   The IAQ in metadata just states certification, not live service.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 SSPsimpleSAMLphp) SP software support the metadata check?

SPs will use 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.

...

Ideally IdPs will receive a desired IAQ from an SP in an AuthnRequest to initiate the process.  The IdP deals with compares the requested IAQ and to its matching rule and interacts with the local IdM system to determine if the current user at hand 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 see receive IAQs from IdPs.

  • Can the Shib (or SSP) IdP be configured to send IAQs without being requested?
  • If so, what are there the appropriate policy knobs (per-SP, per-user, whatever)?