[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Proposal for assertion-level subjects
Well, heck, I'm happy to move subject confirmations up to the assertion level if that will meet the need. This is certainly the simplest possible change: just move the Subject element, as it is currently conceived, up inside the Assertion element. The problem is that we discussed a use case for different confirmations for the same subject, and if we want to allow for this, then things have to remain slightly complicated. The resulting model wouldn't be all that spaghetti-like, I believe, and certainly the whole picture would still be an improvement over the inefficient statement-centric situation we have now. Here is a suggestion for the propositions we must consider in our call tomorrow, in the order we need to consider them: 1. Do we want to allow for *only* one subject per (possibly multi-statement) assertion? (Currently we allow subjects to vary per statement.) 1a. If yes: Do we want to account for *exactly* one subject per (possibly multi-statement) assertion? (That is, do we want to prohibit assertions from being subjectless?) 1b. If no: Is it important to optimize the case of a shared subject across statements? (Currently we don't do anything to help you if you do this.) 2. Do we want to allow explicitly for multiple ways to confirm the same subject? (Currently you can sort of do it, but we don't tell you how, so it's probably not interoperable or efficient.) 3. Do we want to explicitly simplify the current XML model for representing subject and subject confirmation in assertions and statements? 3a. If yes: To what extent should this take precedence over new desired functionality as answered above? Depending on our actual needs, we can make the model match them with a relative minimum of fuss. I suggest that we discuss this early in the call, since a lot of other design decisions seem to be depending on solving this one. Eve Scott Cantor wrote: >>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 don't think we suggested keeping the statement level subjects, just that > it wouldn't be 5% case necessarily for having different confirmations in > different statements, whereas different subjects seems to be. > > >>If someone wants to support a choice between subject >>confirmation methods, we can define an "or" element structure >>in the assertion-level SC. > > > Is the current data model an "and"? I wasn't aware we even said what it > means to have multiple methods in 1.x, but I would have assumed it was an > "or". > > >>If someone wants to have two statements with different SCs, >>they can put them in separate assertions. > > > Certainly an option I would not object to. -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Products, Technologies, and Standards eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]