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