OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: RE: XACML TC Charter Revision - Strawman


I am not suggesting either. SAML (and I) assumes that you know where to go to get an Authorization Decision and that the PDP you ask knows how to compute the answer. I see XACML as currently chartered as a good way to provision a PDP with policies. This is completely outside the current SAML scope. I also see XACML as a way of providing a more complete Authorization Decision Assertion, as in case #2 below. I think what will happen in SAML v1 (at least with our product) is that you will get an answer, but not all the information that was used to make the policy decision will be included in the response. For example, you will ask Can Joe access x? and you will get the answer Yes, joe can access X , but the fact of the matter is the same request would get a different answer 1 sec later. Also perhaps it didn't even matter that it was Joe. Probably for accountability purposes that is good enough, but I continue to be concerned that the assertion will be wrongly construed. Case #3 came from the fact that we keep punting anything that looks complicated and saying XACML will take care of that. Since I have been prominent among the punters (that's a joke, Phill) I started thinking about how XACML might help us with our current major struggle -- Requests. It occured to me that although requests for policies are not the same as policies, perhaps we could steal some bits of XACML for our purposes. This would help justify my position of saying do something simple now and leave a hook for XACML . Hal >