RE: [security-services] Propose addition of a SubjectRef element

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

> Since assertions are the unit that gets shuttled around, we won't have 
> any problems with (say) caching of a statement that is missing its 
> relevant subject information, right?

We'd have exactly the same problem with a "default" subject. Since
Conditions is normative and is not part of the statement, I see no way to
carry a statement independently anyway.

>   I can't help feeling that it privileges the statements that get lucky 
> enough to actually contain the real subject info.  (It would be "cleaner"
to
> put the shared subject info at the assertion level, as we 
> do some other pieces of shared info, but then sometimes you'd still need 
> per-statement subject info, which wrecks the cleanliness in a bunch of 
> ways.)

As I said, I think that's far more complex to specify in the abstract.
Personally, I'd rather pull it out and eliminate the ambiguity of statements
with different subjects altogether, but I assumed we weren't prepared to
change that much.

> And are there any ill effects if you make a forward reference in 
> terms of document order?

We can check, but I certainly doubt it. I suppose it's an issue with some
forms of SAX processing, but if we start designing around streaming of
assertions, we're diving down a deep rathole. XML Signature is virtually
DOM-centric anyway.

I'll fully support either this or a complete refactoring of Subject out, but
I think optionally doing it is worse than either of those.

-- Scott