[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: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]