OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Questions re <ConfirmingSubject>


On reading the text (3.4.1.2) in core-2.0-draft-06, I'm wondering about a
couple of aspects of <ConfirmingSubject>:

If (per lines 1672-1674) an <AuthnRequest> names one or more optional
entities expected to be able to confirm the resulting assertion, does this
mean that the assertion cannot also be confirmed by others if they can
satisfy the confirmation method?  In other words, is the facility to name a
particular entity a hint, or does it constrain the set of possible
confirming subjects?

The clauses at 1672-1674 and 1677-1679 cite MUSTs for identified entities
having the ability to confirm assertions per the designated confirmation
method.  Unless I'm misunderstanding, this seems like an unusual sort of
MUST from a protocol conformance perspective: the entity emitting the
AuthnRequest can't necessarily know whether the (potentially independent)
confirming subjects will have all the prerequisites they'll need to confirm
the assertions once they receive them, and those subjects' eventual ability
to confirm doesn't impact the ability to emit the AuthnRequest and receive
an assertion-bearing response.  The returned assertions won't be useful to
an entity lacking the ability to confirm them, but this doesn't seem like a
MUST on the AuthnRequest emitter in the RFC-2119 sense.

--jl



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]