RE: [security-services] AI: proposed text for core Section 4

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

> Overall I think the proposed versioning text is really good. Scott, if 
> you agree with the nature of the comments below but don't want to 
> attempt a rewrite along these lines, let me know and I'll try to make 
> time to do it myself...

I should have some time to make them, they don't seem huge.

> Small comment: I think we want to refer to "the SAML specification set" 
> and not just "the SAML specification", since it's made up of several 
> discrete documents.  This is the wording we use on the website.

Fine by me.

> Big comment: Given that the assertion and protocol are documented in the 
> same spec, and given that we've said we'll give all the specifications 
> in a set the same version, I think it's confusing to have both a SAML 
> Assertion Version section and a SAML Protocol Version section.

That makes sense. I copied those sections from the original version of course, so that's the biggest reason they're separate. And of
course they could be separate values, but I later end up saying they won't be.

> Finally, it seems a bit disingenuous to say that the appearance of a 
> version number in the namespace means nothing.

That wording came from my original draft document, in which the context was that it means nothing in an "XML context", which is
strictly true. A namespace is just a string.

> The third paragraph in that section pretty much backs off of the strong
> wording in the second paragraph anyway.  I would be willing to sign up for 
> namespace versions that are not orthogonal but, rather, that can be
> expected in normal circumstances to contain an X.0 designation during a
> spec set's journey from X.0 to X.n, and then change to Y.0 whenever a major
> revision happens.  Or, if they're really orthogonal, then let's commit to 
> removing version numbers from them in the future.

I had no real objection to putting the numbers there, but they are mainly for human interpretation, not for machines. That's the
point I was trying to make, so I can word that better.

> Regarding your other notes below, I'm happy to add entries to the 
> glossary once we formally agree on the new terminology (or did we 
> already?).  I get backwards compatibility, but I always have trouble 
> making intuitive sense out of forward compatibility...

It's a bit convoluted, but it mainly just means that the new 1.1 messages will be usable by a 1.0 implementation (or not). By adding
those optional attributes, we've not adhered to that guideline, since strictly speaking those attributes are illegal to an old
implementation unless it updates its schema/expectations.

It's not impossible for a 1.0 implementation that wasn't validating to be fine with the new format, but we can't assume that.

> And it's a great idea to add something about profile versions, once we 
> know what we want to say.  But maybe, since we've pushed off a 
> refactoring of Bindings and Profiles until V2.0, we can do "lazy 
> writing" of this part.  (We will probably then have a total of three 
> versioning types: spec, namespace, and individual profile.)

Undoubtedly.

-- Scott