RE: [security-services] Does anyone create assertions with more thanonesubject? (was RE: [security-services] Retracting earlier SubjectRefsuggestion)

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

> I'd be happy to move a proposal to *completely remove* the 
> subject from the Statement element, and have a single subject 
> in each assertion. I believe that we fell victim to 
> optimizing the 1-percent case when we moved the subject into 
> the statement in the first place.

That's certainly my view, but I wasn't sure how people felt about it. I
would second such a motion.

> 2) some use cases might have statements with no subject

I have no doubt that's true, but Subject should be optional in the
assertion, and if you include a subject for some other statement, it should
be clear for statements that never have subjects that the subject doesn't
apply to it. As I said, the only corner case is a statement that might or
might not have a subject and then you'd need the indicator you mentioned.

> (here's a tricky aside: when a SAML assertion is used as a 
> WS-Security token, and that token is taken to imply the 
> "sender" of a SOAP message, what happens when there's more 
> than one subject in the assertion?)

Exactly. Every actual application/profile of SAML ends up having to either
ignore this, or address it in their profile to preclude it or explain what
the heck it means.

> As for the second justification, we could easily define a 
> "subject not specified" indicator, either by making the 
> content of the Subject element optional (which I prefer) or 
> by specifying a "no subject" URI to tag the existing element.

I think it's clearly got to be optional, and we have no corner cases where
we'd even need the "not specified" indicator.

> And, to try and head off another question: what about doing 
> something like holder-of-key confirmation when there's no 
> subject?

By this I assume you mean the case where Subject has only
SubjectConfirmation and no NameIdentifier? I think in my last proposal about
AuthnRequest I assumed that one would use that formulation to represent
subjects with security tokens, but as I said in there, it's pretty awkward
and it requires ignoring the SubjectConfirmation piece in some cases, so
that's not good.

> "SubjectConfirmation" to hold the indicator. Long-time SSTC 
> members have heard this from me before: what we really need 
> is a <Condition> element that says "assertion can be relied 
> upon if used in a context traceable to holder-of-key"; this 
> doesn't imply any relationship between the subject of the 
> assertion and the sender of the enclosing message, but allows 
> the issuer of the assertion to control who can forward the assertion.

It's certainly easier for me to imagine how the AuthnRequest would work in
the case where you want multiple entities to be able to use the assertion.

Basically, I'm all for radical change because I'm not currently using these
features and believe we're undermining and complicating the use cases that
need them with the current schema. Obviously the time fix it is now or
never, but I'll just leave it at that.

-- Scott