Eve Maler comments on new Draft SAML Profile

[Anne Anderson <Anne.Anderson@sun.com>]

I pinged Eve for comments and here is her response.  It looks like 
everyone is in agreement that we should NOT define XACMLAssertion or 
XACMLAdvice elements and types.  I will remove those from the next 
revision, and include Scott's example of how to embed a new statement 
type in a SAML Assertion:

<saml:Statement xsi:type="xacml-saml:XACMLStatementType">

As he points out, we don't need to do anything special for the Advice 
element, since it already allows <any namespace="#other">.

Regards,
Anne
-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA

--- Begin Message ---

• From: "Eve L. Maler" <Eve.Maler@sun.com>
• To: Anne.Anderson@sun.com
• Date: Fri, 12 May 2006 09:32:56 -0700

I'm glad you pinged me...  It seems that, whenever I put a message 
aside to respond to "later", later never comes!

Scott is much more experienced with using parsers and SAML APIs in 
the wild than I am, not to mention having lived through Liberty's 
first use/extension attempts of SAML, and so I respect his opinion. 
  It seems he's saying two things:

- It's better to use the original SAML element, with just an 
xsi:type on it, for common SAML processing semantics (he's a better 
judge than I on this), and

- the structural changes you need are well accommodated in most 
cases by the extensibility and wildcards already provided by SAML (I 
don't recall having gone into a lot of detail in reviewing your 
specific changes before).

I hope my earlier advice didn't lead you to make a whole bunch of 
expensive design decisions that you now wish to undo...  That said, 
I think Scott's and others' advice seems sound.

	Eve

Anne Anderson wrote:
> Hi Eve,
> 
> I would like to ping you on this, as I hope to do another revision in 
> June.  In the e-mail from you that I appended below, you said "I think 
> it would be reasonable for XACML to define an element in its own 
> characteristic namespace and bind this type to it, though, since you 
> want the whole thing to be easily recognizable for what it is: an 
> XACML-defined query."  Along those lines, I defined
> 
>  XACMLAuthzDecisionQuery: holds an XACML Request
>  XACMLAuthzDecisionStatement: holds an XACML Response and optional copy
>       corresponding request
>  XACMLPolicyQuery: requests one or more XACMLpolicies
>  XACMLPolicyStatement: holds XACML policies
> 
> I think those are fairly straightforward.
> 
> More controversially, I defined:
> 
>  XACMLAssertion: can hold an XACMLAuthzDecisionStatement or
>       XACMLPolicyStatement or XACMLAdvice
>  XACMLAdvice: can hold an XACMLAssertion
> 
> My thinking was that using the XACML... name made it clear that we were 
> using an extended form of Assertion or Advice.  Scott Cantor, in his 
> attached e-mail, thinks this is a mistake, as have several others.
> 
> Could you weigh in?  I am not an XML expert, and don't really have much 
> experience with it, so I am happy to go whichever way those more expert 
> recommend.  I may have misinterpreted your suggestion to make these 
> "easily recognizable for what it is: an XACML-defined []".
> If you want to see the draft spec and schemas, they are at:
> http://www.oasis-open.org/committees/download.php/17672/xacml-2.1-profile-saml2.0-wd-1.zip 
> 
> but the questions I have should not require delving into the actual 
> documents.
> 
> Thanks,
> Anne
> 
> ------------------------------------------------------------------------
> 
> Subject:
> RE: Draft new version of the SAML 2.0 Profile of XACML 2.1
> From:
> Scott Cantor <cantor.2@osu.edu>
> Date:
> Wed, 19 Apr 2006 13:23:57 -0400
> To:
> Anne.Anderson@sun.com
> 
> To:
> Anne.Anderson@sun.com
> CC:
> Eve.Maler@Sun.COM
> 
> 
>>I would appreciate any comments you have.  Some of you have more 
>>experience using the SAML Profile of XACML than most of the XACML TC 
>>members, so your expertise will be appreciated.
> 
> 
> I haven't gone through this in detail yet, but I would strongly urge some
> significant changes to the schemas. In particular, I think the heavy use of
> sequence extensions and replacement of SAML elements like Assertion and
> Advice are the wrong way to approach this kind of extension. It was the same
> mistake Liberty made originally, but with SAML 1.1 we didn't have the schema
> right to provide alternatives.
> 
> You have the basics all there correctly, new Statement types, new Request
> and Response message types, etc. But that's all you should need to do. The
> core Assertion and Advice elements are already extensible to include new
> statement and advice content, and I think it would be a mistake to force
> these XACML elements to the end of the those sequences, or to replace
> elements like Assertion with your own. That makes life much harder for SAML
> applications.
> 
> It is the case that statement extensions can't natively appear in element
> form because we got rid of substitution, but that's still the proper way to
> embed a new statement type:
> 
> <saml:Statement xsi:type="xacml-saml:XACMLStatementType">
> 
> With Advice, you don't need anything special, because the choice already
> includes <any namespace="#other"> in the sequence, so your advice element
> can appear. But since I'm suggesting you don't want or need an
> XACMLAssertion element either, you don't really have ny need for anything
> new in Advice anyway, since Assertions can already appear there.
> 
> -- Scott
> 

-- 
Eve Maler                                         +1 425 947 4522
Technology Director                           eve.maler @ sun.com
CTO Business Alliances group                Sun Microsystems, Inc.

--- End Message ---