[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