Request Language

[Phillip Hallam-Baker <pbaker@verisign.com>]

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