Re: [security-services] The multiple subject issue

[Stephen Farrell <stephen.farrell@baltimore.ie>]

Prateek,

Ok - that sounds like a plan, though I guess someone should check 
(during the last call) that there aren't other comparison cases 
where that isn't the right rule.

Any just to be sure we're on the same page a few more matching
cases (as I understand them) are below.

Cheers,
Stephen.

Let:

s1 = <Subject><n-i=fred/></Subject>
s2 = <Subject><n-i=fred/><s-c=fred-cert/></Subject>
s3 = <Subject><n-i=fred/><s-c=freds-other-cert/></Subject>
s4 = <Subject><s-c=fred-cert/></Subject>
s5 = <Subject><n-i=bill/><s-c=fred-cert/></Subject>

and match(a,b) means "a in auth query, and b in response is ok" and
not-match(a,b) I'll leave to your imagination.

So, your "wildcard" rule means for example:

match(s1,s2)
not-match(s2,s1)
match(s1,s3)
not-match(s2,s3)
not-match(s1,s4)
match(s4,s2)
match(s4,s5)



"Mishra, Prateek" wrote:
> 
> 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
> >>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

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