OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [security-services] Moving subjects up to assertions(disregardfirst reply)

> Perhaps I'm misunderstanding this, but if you take Subject out of 
> SubjectStatement, what is the difference between 
> SubjectStatementAbstractType and StatementAbstractType?

Nothing. But by deriving statements off of distinct anchor types that can't
be mixed, there's a clearer enforcement of the difference between possible
assertion content, without forking off two assertion types.

I'll be honest though, I prefer to just make Subject optional and deal with
the whole thing in prose. I see mostly complexity arising from any use of
XSD to try and deal with this, and I think implementing it at runtime is a
pretty simple thing to do.

> That makes me think Eve had this right - we have an Assertion
> and a "SubjectlessAssertion" - at least conceptually. But I don't 
> think I like that concept so much - especially with multiple statements in
> the assertion. In addition, the pseudo-schema you have below seems to 
> restrict your assertion to non-Subject related statements OR 
> Subject-related statements in one assertion but not both. 
> That is not as flexible as what we have now.

This was very intentional, because I believe that way lies confusion. I
believe Eve's proposal is the same in this respect, unless I misunderstand
it. Also, what's the rule? You can put a subjectless statement in a
SubjectAssertion, but only if there's a SubjectStatement too, since that
"justifies" the presence of the Subject? Weirder and weirder. Clearly you
can't do the opposite...

> 1) We define an container for Subject+SubjectStatements (where 
> SubjectStatement and its ilk are now descended from 
> StatementAbstractType, with additional other Subject related info 
> (SubjectLocality for example).
> 2) SubjectStatements can only appear in the container element 
> (ie. along with a Subject)
> 3) The SubjectStatementContainer and other statements can all 
> exist in the same assertion.

That seems like a possible middle road, I guess. In effect, it makes my two
"choice" options a sequence, at the cost of another wrapper element. I would
still advocate the "distinction without a difference" that seperates the
abstract types underneath the two statement "classes". It makes it
impossible to use xsi:type to do anything unintended.

But my take on this is that it begins to undo the optimization we were after
and argues that we think these two kinds of statements will co-exist often
enough that we need to design for this and isolate them from one another
with a new element. I'm not convinced that's true. (Actually I'm pretty
convinced it's not.)

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]