OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]