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

[Polar Humenn <polar@syr.edu>]

What about the integrity of an assertion that references a subject in
another assertion. Couldn't this situation be really problematic,
especially spoofed by replacing the referenced subject in an assertion
with another assertion with a different subject? Or even an accidental mix
up?

Cheers,
-Polar

 On Tue, 10 Feb 2004, Eve L. Maler wrote:

> 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
>
>
> 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.
>