[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SubjectConfirmation errata
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."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]