[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] SubjectConfirmation errata
[PM] Scott, I am broadly in agreement with the changes proposed. I am concerned about how relying parties figure out whether they are dealing with an attesting entity distinct from the assertion subject vs. the subject itself. Authorization and other decisions may be driven off this distinction. Processing Logic for determining whether attesting entity == subject in a SAML HoK assertion: ------------------------------------------------------------------------------------------------ 1. Validate proof material (signature, SSL handshake, whatever) against the <subjectconfirmation>/<confirmationdata> elements found in the assertion. 2. At least one <subjectconfirmation>/<confirmationdata> element must correspond to the proof material; otherwise fail. 3. If the <subjectconfirmation> element in (2) does not include a <NameId> element, then attesting entity == subject. 4. If the <subjectconfirmation> element in (2) includes a <NameId> element, compare it to the value of <Subject>/<NameId>. If the two are identical (after normalization), then attesting entity == subject 5. Otherwise, attesting entity != subject. I guess the concern here is with the relative indirectness of the process versus the use of a new condition element that signals the issuers intent (attesting entity != subject). Obviously, there is a cost associated with the latter approach (schema for the new element). But maybe it is worth the expense? SenderVouches is a SAML 1.1 legacy. SAML 1.1 HoK assertions are tightly bound to assertion subjects; SV is a one-off that allows others to speak for the subject. The generalization of HoK in SAML 2.0 removes the need for use of SV. If appropriate, we could even move to deprecate its use in SAML 2.x at some point. [\PM] 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. > > > > >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." > > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]