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

["Philpott, Robert" <rphilpott@rsasecurity.com>]

I'm on vacation and have just been skimming the conversations as time
permits, but it occurred to me that Liberty might present a saml/samlp usage
that (I think) relates to this issue.  

In a Liberty <Assertion> Element, the Liberty AssertionType is defined as an
extension of the SAML AssertionType.  Okay - no problem - they wanted some
extensions.  But the extension they made was to include, as mandatory, an
InResponseTo attribute which is filled in from the RequestID attribute of
the original AuthnRequest message (which is based on
samlp:RequestAbstractType).

Where our current SAML schemas refer to assertion schema elements from
within the protocol schema, Liberty crosses over the other direction as
well. You cannot even build a lib:Assertion without gaining access to the
RequestID from the request protocol message.

So when dealing with the versioning issue we're going to have to keep this
usage of saml/samlp in mind as well.    


Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com 


> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Monday, April 21, 2003 6:02 PM
> To: 'Eve L. Maler'; 'SAML'
> 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