DRAFT
Technical implementation of assurance requires system changes from InCommon Operations, IdPs, and SPs. There are many different scenarios and choices.
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.
Ideally SPs will initiate the assurance flow by including the desired IAQ in the SAML AuthnRequest element.
<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.
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.
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.
SPs may not put IAQs in AuthnRequests but still want to receive IAQs from IdPs.