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

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

It does, but I felt that the relationship between Request/Response and Assertion was arguably a little different than if you drill
down deeply into the schema. At some level, every element could be defined in isolation and then composed together, but we're
explicitly versioning these three elements.

> > 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?

No, I think I mean the other way around...disallowing in prose what the schema would on the surface permit, for example disallowing
a 1.1 assertion in a 1.1 response. I don't think we can realistically permit something that won't validate, unless we change the
decision that the schema is normative.

-- Scott

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