Re: [security-services] AI 0028, summarize versioning questions re:assertions within protocol

["Eve L. Maler" <eve.maler@sun.com>]

Scott Cantor wrote:
> 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.

Meaning that we could have a choice group allowing a 1.0 assertion or a 
2.0 assertion at each spot?  Same would have to go for other saml: items 
that get mentioned in samlp:, which gets ugly.  These elements get 
referenced, and theoretically could use choice groups:

saml:AssertionIDReference
saml:Subject
saml:AttributeDesignator
saml:Action
saml:Evidence
saml:Assertion

These types get referenced:

saml:IDType
saml:IDReferenceType

Since the types are referenced from attribute declarations, and you 
can't do choice groups for attributes (at least not in XML Schema you 
can't :-), this wouldn't even be an option for some constructs.

Yuck.

> 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".

Meaning we could accomplish in prose what we couldn't (easily) through 
the schema in allowing some/all version combinations even if the schema 
disallows it?

> d) ?? Your option here...

Couldn't think of any others.

	Eve

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com