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] | [Elist Home]

Subject: RE: [security-services] The multiple subject issue

There are several challenges on lines 964 - 1000 of core-25.

First, I have noted in 


That we have a problem with the occurrence of <saml:ConfirmationMethod> on
line 996. My belief is that this 
element should be an (optional) <AuthenticationMethod> element.
This is consistent with notes from F2F#3 wherein this field
was called Authntype.


Turning to the more substantive question: what type of matching
should be used for the <saml:Subject> element defined on 
line 971.

The challenge here is that the <saml:Subject> element optionally holds
either or both of <NameIdentifier> or <SubjectConfirmation>.
I would suggest that the absence of either one be  treated as
a wild card. In other words, the requestor is providing as much
information as she has, the responder will match the <Subject> element
against that and return all possible assertions.

Answering Steve's question: whether s1 and s2 are the "same" is a question
the specification should be silent about. The question we need to answer is
what the responder should return when queried with an authentication query
for s1. I would argue that s2 is a legitimate response.

- prateek mishra

>>Prateek said:
>>> Asserting two syntactically distinct subject designators as 
>>"equivalent" is
>>> a whole another matter and one for which we
>>> neither have a use-case or even an extended discussion on the
>>> list.
>>Folks, I'm sorry to be so dim, but, I'm still confused
>>as to whether s1 & s2 are the same. Line 985 of core-25
>>says "MUST be identical", but then goes on to say that
>>"at least one" confirmation method "MUST match".
>>I haven't really looked for other cases where Subject
>>elements might have to be compared but I imagine it'll
>>be a fairly common thing for PEPs/PDPs to be doing.

>>PS: s1 & s2 were:
>>> > 3) Let s1 = <Subject><n-i=fred/></Subject> and
>>> > s2 = <Subject><n-i=fred/><s-c=fred-cert/></Subject> (i.e. s2
>>> > is s1 with the addition of a SubjectConfirmation). 
>>Stephen Farrell         				   
>>Baltimore Technologies,   tel: (direct line) +353 1 881 6716
>>39 Parkgate Street,                     fax: +353 1 881 7000
>>Dublin 8.                mailto:stephen.farrell@baltimore.ie
>>Ireland                             http://www.baltimore.com

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

Powered by eList eXpress LLC