Ron Monzillo wrote:
> Prateek Mishra wrote:
>
> hi Prateek and Scott,
>
>> [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.
>>
> IMV, an entity satisfying the confirmation method has been authorized
> by the
> assertion issuer to use (the identity of) the subject of the assertion.
>
> IMV, if an additional identifier is present it indicates that the
> assertion issuer has authorized
> the attribution of this additional identifier to any entity that
> satisfies the confirmation method.
>
> As such, the presence of this additional identifier indicates that to
> the assertion issuer, the
> attesting entity is different (by this additional attribute) from the
> subject.
>
> is that not sufficient?
>
> Ron
>
>> 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
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
>
