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 

http://lists.oasis-open.org/archives/security-services/200201/msg00262.html

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.

http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-Notes-Hodge
s-WhiteboardTranscription.pdf

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
maximally
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