Re: [security-services] Retracting earlier SubjectRef suggestion

["Eve L. Maler" <Eve.Maler@Sun.COM>]

In the time it took me to compose the message below, a flurry of other 
responses came in...  The schema awkwardness I mention would go away if 
<Subject> were *completely* factored out into the AssertionType level. 
Then SubjectStatementAbstractType could simply go away.  If we thought 
customizers might want to add <Subject> to statements on their own, 
they'd be free to do so as an extension.

	Eve

Eve L. Maler wrote:

> Note that, with Scott's original solution proposal, we could have used 
> XSD's keyref capabilities to scope IDREF values to IDs assigned only in 
> the current assertion element.  But I don't know how interoperable this 
> really is.
> 
> If we agree to "factor out" common subjects, we still have a choice 
> about whether to accept the use case of multi-subject assertions, as 
> Scott notes below.  However, whether or not we accept it, there's still 
> some looming schema awkwardness:
> 
> Any statements without a <Subject> present (which could be *all* of them 
> or *some* of them, depending on the decision above) are still subject 
> statements in the sense that they "inherit" the common subject from 
> above, but if SubjectStatementAbstractType now has an optional <Subject> 
> element in it, where have we gone with that semantic?  Should we just 
> have StatementAbstractType with an optional <Subject> element in it and 
> do away with the "...Subject..." type level?
> 
> Other, more Draconian, solutions (such as splitting into 
> SubjectStatement types and ImpliedSubjectStatement types) seem not worth 
> the trouble.
> 
>     Eve

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com