RE: [security-services] The multiple subject issue

["Mishra, Prateek" <pmishra@netegrity.com>]

The consensus at F2F#5 was to have a single-subject per
statement. At the same time notice that multiple (unrelated)
statements may be present in an assertion. 

One use-case discussed
at the F2F was the scenario wherein an AP creates a bunch of
statements about a principal (described via many different
<subject> elements) and dumps them into an assertion. A
relying party then scrabbles thru the statements and finds
those that it recognizes or wants. My impression is that (at the
cost of some redundancy) this supports the type of processing used in the
Java security model. So, if we have principal P with
names P@work-address.com and P@personal-address.com and attributes
A and B we may end up with:

<Assertion>
Stmnt 1: <Subject><NameIdentifier>P@work-address.com..</Subject>
         Attribute Name A:  Attribute Value: xxxx
         Attribute Name B:  Attribute Value: yyyy

Stmnt 2: <Subject><NameIdentifier>P@personal-address.com...</Subject>
         Attribute Name A:  Attribute Value: xxxx
         Attribute Name B:  Attribute Value: yyyy
</Assertion>

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.


- prateek

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