Re: [security-services] Propose addition of a SubjectRef element

["Eve L. Maler" <Eve.Maler@Sun.COM>]

Since assertions are the unit that gets shuttled around, we won't have 
any problems with (say) caching of a statement that is missing its 
relevant subject information, right?

If that is the case and will remain the case into the forseeable future, 
then this seems like a fine design for solving the problem.  Although... 
  I can't help feeling that it privileges the statements that get lucky 
enough to actually contain the real subject info.  (It would be 
"cleaner" to put the shared subject info at the assertion level, as we 
do some other pieces of shared info, but then sometimes you'd still need 
per-statement subject info, which wrecks the cleanliness in a bunch of 
ways.)  And are there any ill effects if you make a forward reference in 
terms of document order?

	Eve

Scott Cantor wrote:

> Before the issue hangs around any longer, I'd like to propose a solution to
> the issue of optimizing the carriage of multiple statements that share a
> subject in a single assertion by proposing that we add the ability for a
> SubjectStatement to include a Subject element by reference in addition to by
> value.
> 
> This is much more than just a space saver in the case where a non-trivial
> SubjectConfirmation is used, since duplicating the confirmation and then
> possibly evaluating it twice is not good.
> 
> My proposed solution is that we add an ID attribute to SubjectType and add a
> new element/type called SubjectRef that just includes an ID attribute (of
> type IDREF). We then allow SubjectStatement to carry either Subject or
> SubjectRef.
> 
> E.g.
> 
> <AuthenticationStatement>
> 	<Subject ID="sub1"><NameIdentifier>...</NameIdentifier></Subject>
> </AuthenticationStatement>
> <AttributeStatement>
> 	<SubjectRef ID="sub1"/>
> 	<Attribute/>...
> </AttributeStatement>
> 
> I'm open to whatever stylistic choices people want (make SubjectRef contain
> the reference as element content, etc.).
> 
> I believe this will be easier spec-wise than trying to create the notion of
> a "default" subject in the current data model and this should solve the same
> set of problems.
> 
> -- Scott
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com