[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] The multiple subject issue
I agree with Eve here, I think that the decision to be restrictive about the subject was unnecessary. I certainly did not experience the confusion that some thought might be created. However we discussed this on several conference calls and F2Fs and several votes were taken which I lost so I don't think we should reopen the issue in last call. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu] > Sent: Thursday, January 31, 2002 5:04 AM > To: Hallam-Baker, Phillip > Cc: OASIS Security Services TC > Subject: Re: [security-services] The multiple subject issue > > > > On Wed, 30 Jan 2002, Hallam-Baker, Phillip wrote: > > > A statement can have exactly ONE subject that may be desribed by a > > Name Identifier alone, OR a Name Identifier and subject confirmation > > OR a subject confirmation alone. > > Thanks for clarifying this. I found the discussion of > multiple subject > names on the last conf call deeply puzzling because I was under the > impression that we had agreed to the model you describe here, > which makes > concerns about the semantics of multiple subject names per statement > simply go away because multiple subject names don't exist. > It was this > clarification we sought when discussing this at the last F2F and I'm > hoping we have found it. > > The flip side of this is the claim, which I think Eve was > championing on > the last call, that multiple subject names in a statement > would be a good > and useful thing in some situations, and in particular that the Java > "principal" concept needs this. While I'm not intimate with the Java > model for this stuff, let me suggest that the expression of security > properties and relationships among multiple named entities (eg, "the > entity 'cn=Joe,ou=foo,dc=example,dc=com' with subjectConfirmation > publickey XXX also has the name 'joe@example.com' with > subjectConfirmation > kerbTGT YYY") is the sort of thing that can and should be > supported either > with authentication statement extensions with well-defined > semantics, or > with attribute statements. Having a single subject per statement will > allow us to avoid this semantic quicksand for now and get our > spec out the > door. > > - RL "Bob" > >
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC