[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Request Language
One of Dave's points concerns the request language. I thought I would state some of the issues that lead to the bits I wrote, I did not do this at the time since my original idea was that my request language was an interim and that the protocols group would soon come up with a replacement: 1) Simplicity of Implementation I do not like the idea of a complex request language in the manner of SQL. In particular the idea of regular expressions, structured queries etc. appear to me to require a deep level engagement in the type of policy concerns the group is trying to avoid. 2) Comprehensiveness It should be possible to state a query in as much or as little detail as the case requires. 3) Implicit Context In many cases the context for the query need not be stated in the protocol since it is implicit in the context of the system configuration. So if the PDP is asking for an assertion concerning Alice from the Acme credit rating service it is not necessary for the request to state that a credit rating is required in the response since that is all the service returns. 4) Policy Neutral As discussed in (1) there is potential for a query language to become enmeshed in policy. I do not like this since even if XACML meets all the requirements set for it, XACML cannot solve the entire auth policy problem. In particular credit payment authorizations require code since they are stateful and an approval is a non-linear function of the payees past behavior, the goods involved, geographic location etc. One consequence of (4) is that the query language at present allows for stateful access policy (access to the Coke file causes future requests for access to the Pepsi file to be denied), but it does not support (strictly does not distinguish) the type of 'single use' authorizations that some might want, so the Alice might be authorized to access the 'wish' file three times only. One way to address this point would be to introduce separate identifiers for each permitted instance of accessing the wish file, so we have wish-1, wish-2, wish-3 and treat the authorizations separately. This has some nice properties so that if a response is lost for some reason the auth question may be re-issued without it counting as a separate wish. In my discussions with Joseph Reagle concerning use of XML Query in XKMS it appeared that XML Query was a general purpose data-structure query language. This sounds to me to be somewhat overly complex for our purposes. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > You completely diverted from the issue that I raised about > quoting scripture > from authority figures. I'm surprised that my RDF troll > worked, but I do > agree with your sentiment on it. As Jeff Hodges will attest, when I discussed XKMS with Tim he complained that it 'was not standards based' because we had not used RDF :=}
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC