[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Any kind of policies in a request
David, When we discussed this in Luxembourg, I assumed you intended to add an ANY to the decision request in the SAML Profile, not to the definition of XACML policies. I was struck how both you and Prateek have said to me, the wire protocol decision request is the most important part of XACML because it allows a PDP of any kind to be called. It seems to me logically this is the place where additional information, such as more policies might be needed by a non-XACML PDP. My main concern is to make it clear that what ever is used here should be profiled and a PDP receiving a request with contents it does not understand MUST return Indeterminate with some appropriate error code. Hal -----Original Message----- From: Erik Rissanen [mailto:erik@axiomatics.com] Sent: Monday, November 23, 2009 7:12 AM To: David Chadwick Cc: Rich Levinson; xacml Subject: [xacml] Any kind of policies in a request David, I have been thinking more about this. I think that an extension point to plug in any kind of policy format does not belong in the XACML core schema, and thus not in the <Request>. The XACML schema is for defining the XACML language, and we would lose some of the benefits of standardization by allowing any content in it. However, SAML defined in the past a protocol for AuthZ query/response. It is my understanding, and please correct me if I am wrong, that there was an agreement between the SAML and XACML TCs that the XACML request schema would supersede the SAML AuthZ formats, and SAML dropped their own. The original SAML protocol was ambiguous regarding the policy language. If we think of the XACML SAML profile to carry the legacy of the original SAML AuthZ protocol, than I guess it would make sense to support other policy languages since the original protocol was not XACML specific. What do the rest of the TC see as the scope of the XACML SAML profile? Is it just about supporting XACML, or does it have a wider scope? Best regards, Erik David Chadwick wrote: > Subsequent to the minutes > > Rich.Levinson wrote: > >> >> Proposed schema change for policies and discussion from >> David Chadwick and response from Erik: >> http://lists.oasis-open.org/archives/xacml/200911/msg00023.html >> >> Erik: David proposed req ctx schema for ext pts xml any, where >> can put proprietary policy lang things; doesn't make sense >> to std on any policies in fmt; suggest using saml/xacml >> mechanism >> Rich: sees it as potentially disruptive, effectively allowing >> elements as children of PolicySet >> Bill: proprietary elements don't make sense; need further info >> to be considered; >> >> defer topic until more info from David addressing concerns >> in email and minutes >> > > It makes sense because we cannot assume that every PDP talks the XACML > policy language. However, it is possible to make every PDP talk the > XACML request/response context. Once we have sticky policies and > obligations which we pass around a distributed system we need to be > able to cater for multiple policy languages. If you see my > presentation at W3C yesterday at > > http://www.w3.org/2009/policy-ws/slides/Chadwick.pdf > > and look at slide 5 from 11, you will see why we need to relax the > schema requirements on the policy element in the SAML-XACML profile, > otherwise we have no standard way of passing a sticky policy to an > AIPEP or Master PDP. > > regards > > David > > > > > ***************************************************************** > David W. Chadwick, BSc PhD > Professor of Information Systems Security > The Computing Laboratory, University of Kent, Canterbury, CT2 7NF > Skype Name: davidwchadwick > Tel: +44 1227 82 3221 > Fax +44 1227 762 811 > Mobile: +44 77 96 44 7184 > Email: D.W.Chadwick@kent.ac.uk > Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html > Research Web site: > http://www.cs.kent.ac.uk/research/groups/iss/index.html > Entrust key validation string: MLJ9-DU5T-HV8J > PGP Key ID is 0xBC238DE5 > > ***************************************************************** > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]