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: RE: [security-services] editorial comments on binding and core drafts


> 1355-1357 suggests that minor versions are backwards 
> compatible. This is not in fact the case with SAML 1.1. 
> Should we call attention to that SAML 1.1 is not backwards 
> compatible with SAML 1.0 admittedly in only a very narrow 
> aspect of the schema.

That's a valid point. We did admittedly break the one rule I was pretty sure was a given. ;-) I guess that means we change the
language to relax it a bit to "we really want to try to do it this way, but..."

I guess one way out is to point out that in cases where deficiencies in the spec are uncovered that in fact harm interoperability,
that might take precedence. But there's no denying that this kind of schema change without a namespace change is a drastic step.

> 1398 Is there some additional context here? How can we 
> prevent a SAML requestor from arbitrarily issuing such a request?

That language needs to be cleaned up (Rob also noted this in his comments) to say that the rule is that the requester MUST not
generate a message with a version that *it* does not support, and same goes for a responder and an authority issuing assertions.

It's not assuming that the parties communicating always know each other's capabilities, though at some point metadata probably will
be involved.

-- Scott



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