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

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:


These types get referenced:


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.


> 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 Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com

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