RE: [security-services] Proposal for assertion-level subjects

["Reid, Irving" <irving.reid@hp.com>]

Argh! When I proposed assertion-level subjects, it was because I wanted to REDUCE complexity. All this talk of having both assertion and statement-level subjects, and confirmations, is making my head spin.

I want ONE subject/subject confirmation in each assertion, at the top level. NO statement-level elements.

I'm sick of optimizing the 5% case, at the expense of hundreds of lines of hard-to-test, hard-to-maintain code in *each* implementation.

If someone wants to support a choice between subject confirmation methods, we can define an "or" element structure in the assertion-level SC.

If someone wants to have two statements with different SCs, they can put them in separate assertions.

Any Other Path Leads To Madness.

 - irving (at least for me) -
 

> -----Original Message-----
> From: Eve L. Maler [mailto:Eve.Maler@Sun.COM] 
> Sent: February 26, 2004 06:34
> To: Scott Cantor
> Cc: 'Greg Whitehead'; security-services@lists.oasis-open.org
> Subject: Re: [security-services] Proposal for assertion-level subjects
> 
> 
> Ah, right.  I hadn't included subject confirmation info in the higher 
> level in my proposal, but it could be added optionally to the 
> assertion 
> level, with the semantic that if it's present, any absence of 
> it at the 
> lower level means to pick it up as a default.
> 
> 	Eve
> 
> Scott Cantor wrote:
> >>One of the benefits that I was looking forward to with 
> assertion-level  
> >>subjects was only having to confirm the subject *once* in 
> the common  
> >>case, and I'm not sure how that is impacted by this proposal.
> >>
> >>In the presumably common case that there is one 
> SubjectConfirmation  
> >>method that a number of statements share, does this 
> proposal allow an  
> >>assertion-level expression of that method?
> > 
> > 
> > I think that has to be part of the solution, or we lose 
> much of the benefit.
> > 
> > In fact, it seems clear to me that Subject as currently 
> defined is really
> > one of two things:
> > 
> > 	An identifier + optional subject confirmation
> > 	or
> > 	subject confirmation
> > 
> > That suggests that what we're really doing is giving 
> assertions a single
> > subject identifier (via a choice of BaseIdentifier, NameIdentifier,
> > EncryptedIdentifier) and then separating out subject 
> confirmation from that.
> > So Subject per se is gone.
> > 
> > My assumption is that SubjectConfirmation itself becomes a 
> sequence of
> > elements, each one containing an optional identifier, a method, and
> > method-dependent data.
> > 
> > The sequence would appear both in the assertion (following 
> the subject
> > identifier) and in each statement.
> -- 
> Eve Maler                                        +1 781 442 3190
> Sun Microsystems                            cell +1 781 354 9441
> Web Products, Technologies, and Standards    eve.maler @ sun.com
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/security-services
/members/leave_workgroup.php.