RE: [security-services] Retracting earlier SubjectRef suggestion

[Scott Cantor <cantor.2@osu.edu>]

> 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.

True, but the answer is not very. I wasn't gonna go there. It probably
wouldn't bother anybody to do it but almost nothing enforces keyref that I
know of, or at least that's what I've been led to believe. One reason being
the XPath aspect of it, I think.

> 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?

Well, assuming for the moment we're not talking about actually factoring
Subject out, my assumption is that SubjectStatement carries an optional
subject and has the semantic that such a statement requires either an
in-band element or the assertion-level element be present. Thus my point
that it's no longer possible to assume SAML "validity" from schema validity.
I see no way around that even if we did factor Subject out, since it would
be optional either way. Without co-constraints, not much we can do about
that.

StatementType could be left for others to derive truly Subject-less
statements from.

-- Scott