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: Retracting earlier SubjectRef suggestion

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

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

-- Scott

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