[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Propose addition of a SubjectRef element
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]