FW: [security-services] Does anyone create assertions with more than one subject?

["Mishra, Prateek" <pmishra@netegrity.com>]

There is an ongoing discussion on this topic on the SAML list. We would be
interested in hearing from anyone who has used this feature in a SAML
*deployment*.

- Prateek Mishra


-----Original Message-----
From: Reid, Irving [mailto:irving.reid@hp.com] 
Sent: Wednesday, February 11, 2004 10:55 AM
To: Scott Cantor; SAML
Subject: [security-services] Does anyone create assertions with more than
one subject? (was RE: [security-services] Retracting earlier SubjectRef
suggestion)

I was trying to write up some examples for another issue, and I also tripped
over the ugliness of having a subject in every statement.

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.

If I remember correctly, the justification was two-fold:

1) issuers could save effort (particularly with digital signatures) by
combining statements about multiple subjects into single assertions

2) some use cases might have statements with no subject


The first justification seems particularly bogus to me. I don't know of
anyone creating assertions with more than one subject, and the increased
size and processing effort for subject-in-statement on the 99% of assertions
with a single subject more than outweigh any added costs for an issuer
having to create two assertions if they really want to talk about two
different subjects.

Remember that the spec EXPLICITLY requires that there MUST NOT be any
implied semantic connection between subjects, when more than one is included
in the same assertion.

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

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.



And, to try and head off another question: what about doing something like
holder-of-key confirmation when there's no subject? Well, my opinion is that
you're not doing "subject confirmation", so it's silly to use an element
called "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.

 - irving -

> From: Scott Cantor [mailto:cantor.2@osu.edu] 
> 
> I did some back-of-napkin implementation of my SubjectRef 
> proposal, and even
> though it's more elegant to specify and is more consistent 
> with the current
> spec, it's a little harder to implement than defaulting the 
> Subject would
> be.
> 
> Polar's comment also got me a little paranoid, only in the 
> sense that one of
> the advantages of SubjectRef is that I was hoping to keep the 
> relationship
> between schema validity and SAML validity. Since multiple 
> assertions can
> appear in an XML document, this wouldn't hold with my 
> suggestion any more
> than it does in Conor's, so it's a lose either way for me.
> 
> So I retract that idea and suggest we go ahead and at least 
> add an optional
> <Subject> ahead of the statement sequence and then make 
> <Subject> optional
> in the SubjectStatementType. I can't think of any actual use 
> cases for a
> statement that would optionally have a "primary" subject, so 
> there's not
> much point in worrying about weird hypotheticals.
> 
> That said, I'd like to ask what the use cases are for multiple
> SubjectStatements with different Subjects? I can't see any current or
> proposed protocols that would be likely to result in such a 
> thing. If there
> aren't any, then why do we need to support it? It certainly 
> creates enough
> headaches.
> 
> -- Scott

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
_workgroup.php.