SubjectConfirmation errata

["Scott Cantor" <cantor.2@osu.edu>]

This is the AI associated with the language around the confirmation elements
and clarifying the intent of the embedded secondary identifier. It also
encompasses Prateek's errata (PE 40), and adds some additional "SHOULD"
guidance around cases where multiple attesting entities (other than the
subject) are known/intended. The intent was certainly that each
SubjectConfirmation would identify at most one such additional party, so
multiple elements should be used in such cases.

I've included text in core, and cleaned up/extended the language for both
holder of key and bearer. Bearer was far too strictly worded, and was
botched, much like holder of key was. I did not touch sender-vouches, as I
quite simply do not understand it, so I'm not stepping in there.

My proposals follow.

-- Scott

Core:

Insert the following at line 698:

"If the <SubjectConfirmation> element in an assertion subject contains an
identifier that is distinct from the identifier in the enclosing subject,
the issuer authorizes the attesting entity to wield the assertion on behalf
of that subject. A relying party MAY apply additional constraints on the use
of such an assertion at its discretion, based upon the identities of both
the subject and the attesting entity.

If an assertion is issued for use by an entity other than the subject, then
that entity SHOULD be identified in the <SubjectConfirmation> element."

Profiles:

Replace lines 335-337 with:

"As described in [XMLSig], each <ds:KeyInfo> element holds a key or
information that enables an application to obtain a key. The holder of one
or more of the specified keys is considered to be an acceptable attesting
entity for the assertion by the asserting party."

Insert the following at line 341:

"If the keys contained in the <SubjectConfirmationData> element belong to an
entity other than the subject, then the asserting party SHOULD identify that
entity to the relying party by including a SAML identifier representing it
in the enclosing <SubjectConfirmation> element.

Note that a given <SubjectConfirmation> element using the Holder of Key
method SHOULD include keys belonging to only a single attesting entity. If
multiple attesting entities are to be permitted to use the assertion, then
multiple <SubjectConfirmation> elements SHOULD be included."

Replace lines 361-363 with:

"The bearer of the assertion is considered to be an acceptable attesting
entity for the assertion by the asserting party, subject to any optional
constraints on confirmation using the attributes that MAY be present in the
<SubjectConfirmationData> element, as defined by [SAMLCore].

If the intended bearer is known by the asserting party to be an entity other
than the subject, then the asserting party SHOULD identify that entity to
the relying party by including a SAML identifier representing it in the
enclosing <SubjectConfirmation> element.

If multiple attesting entities are to be permitted to use the assertion
based on bearer semantics, then multiple <SubjectConfirmation> elements
SHOULD be included."