[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] The multiple subject issue
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC