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: AI 0028, summarize versioning questions re: assertions within protocol


On the 15-April call, my proposed text for the Versioning section in the core doc was accepted, but a new set of issues orthogonal
to that text arose. I agreed to try and describe them.

The central question is what to say about the version of an Assertion that can be carried in a particular version Response. Strictly
speaking, responses mostly just carry assertions without any real interaction with the payload, so there don't appear to be any
obvious issues from a profiling perspective.

But, since the Response type is schema-defined to carry Assertion elements from a specific namespace, the interactions between the
assertion namespace and the assertion version would currently affect what could be carried. Specifically, a 1.0/1.1 Response could
not carry, perhaps, a 2.0 Assertion assuming the 2.0 assertion namespace is different.

In my recently accepted text, I make clear that we expect namespaces to change or be introduced only during major revisions, but
this is not a 100% certainty. We could however approach the problem from the namespace side, and simply say that the Response schema
definition makes it evident that only Assertions of versions defined within the referenced assertion namespace can be carried. This
would permit a 1.0 Response to carry a 1.1 Assertion or vice versa, but would make it explicit that a namespace change later would
dictate whether the new assertions could be carried in that fashion.

There doesn't seem to be any obvious reason to prevent the mixing of versions, since 1.1 implementations need do nothing to permit
it, and 1.0 implementations already have to deal with a schema update for the ID attribute issue. In most minor revisions, we expect
forward schema compatibility, so an old Response ought to be capable of handling a slightly newer assertion in future cases.

Summing up, I see these options:

a) Explicitly disallow mixing of versions to avoid potential complications that might arise in future work.

b) Rely on the namespaces to dictate what can and can't happen, which implies that we allow mixing of 1.0/1.1 and may explicitly
decide to permit 2.0 response to carry 1.1/1.0 assertions if we design the schema that way.

c) Try and think through use cases (or a lack of) that might lead to processing rules like "newer responses can carry older
assertions but not vice versa".

d) ?? Your option here...

-- Scott



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