MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Eve Maler comments on new Draft SAML Profile
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 ---
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 ---
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]