XACML questions for XDI TC call

["Drummond Reed" <drummond.reed@cordance.net>]

Anne & Hal,

First, thank you for attending the XDI TC call next Monday starting at 8pm
EST. To take as little of your evening as we can, we've place you first in
the agenda after roll-call. The call-in info is:

US Domestic Toll Free: 866.365.4406
Intl. Toll: (+1) 303.248.9655
Meeting ID: 6022117

Anne asked us to send a list of questions before the call, which follow
below. But first, a little context. The purpose of XDI is to provide a
standard, generalized way to share, link, and synchronize data between any
two applications. It's based on the concept of XDI documents -- an XML
schema-neutral way of persistently identifying and linking data using XRIs
(Extensible Resource Identifiers), a URI-compatible abstract identifier
scheme developed by the OASIS XRI TC. 

An analogy that XDI TC member Dave McAlpin likes to use is, "XDI documents
are to data what SOAP envelopes are to messages."  In other words, just as
the job of SOAP envelopes is to associate arbitrary XML-encoded metadata (in
the form of SOAP headers) with a message, the job of XDI documents is to
associate arbitrary XML-encoded metadata with data. XDI goes on to define a
RESTful Web service based on exchange of XDI documents to share, link, and
synchronization this data and metadata. We will also define a binding to
both SOAP and HTTP, i.e., in the XDI/SOAP binding, SOAP envelopes will carry
XDI documents as their payload, whereas in the HTTP binding, XDI documents
will be exchanged "raw" over HTTP.

The key benefit of a schema-neutral way of persistently referencing and
exchanging data is that it gives you a standardized way to link and
synchronize it across applications. XDI links are self-describing using
other XDI documents called link contracts. Link contracts can control any
aspect of an XDI data sharing relationship between two authorities, from how
they will authenticate each other to how they will synchronize updates to
the linked data. (For more detail, see the Intro to XDI white paper at
http://www.oasis-open.org/committees/download.php/6434/wd-xdi-intro-white-pa
per-2004-04-12.pdf) 

Most relevant to our conversation, link contracts are the mechanism by which
policies of any kind can be "bound" to the shared data. For example, a link
contract between Data Authority A and Data Authority B may say that B has
access to A's resources X, Y, and Z under policy P.

Given this background, here is our initial list of questions:

* How do you pronounce "XACML"? (Is it "Ex-akML" or "ZakML" - we've heard
both.)

* Does XACML only work against XML-described resources, i.e., XML documents,
or can it provide access control for any URI-identifiable resource?

* At first reading it's not clear exactly how XACML reference policies,
policy elements, attributes, etc. It appears to use both URIs and XPath
expressions. Is one or the other preferred? Are their other referencing
mechanisms?

* How should we reconcile the XACML glossary definitions of "Resource" and
"Subject" and the URI/XRI glossary definition of "Resource" (anything
identifiable) which would include "Subjects"? What is the XACML equivalent
of what the XRI & XDI glossary calls an "Authority" (a Resource that
controls other Resources)?

* Given our description of XDI link contracts - XDI documents that govern
the sharing of other XDI documents - is there a reason that XDI link
contracts should favor: a) physically containing instances of the XACML
policies the author wants to bind with specified data, or b) referencing
those policies externally with XRIs? Or does it not matter?

* Clearly XACML policies are intended to be portable across an authority,
such as a single enterprise. Are they also intended to be portable across
authorities, such as across the members of a consortium?

* Could an XACML policy be used to describe the usage controls on a shared
piece of data? For example, could Authority A share Resource X (say a home
phone number) with Authority B and have the link contract specify that
Authority B may only allow access (in their own domain) to Resource X under
XACML Policy Y?

* At the SIMC meeting in New York in February, Hal Lockhart mentioned that
an XACML policy could be used to select the set of nodes in an XML document
that satisfy that policy. Is this the case? (This could be enormously useful
in XDI, as policies could be a particular efficient way of selecting subsets
of data to be shared from a larger XDI document.)

* Do you see XRIs and XDI as one means of accomplishing the "policy
referencing and retreival" and "attribute value resolution" processes that a
PDP must execute in order to assemble a fully-resolved XACML authorization
decision request?

* Are there other ways in which XRIs and XDI might be helpful to XACML?

* What is the status of XACML 2.0? When are the specifications expected?
Should that be our target for compatibility?

* Will XACML 2.0 be harmonized with SAML 2.0?

* The XDI TC will be completing its requirements stage in early May and
beginning specifications. How would you recommend the XDI TC work with the
XACML TC to achieve the best synergy between our efforts?

Thank you again for your time, and we look forward to talking with you on
the call.

=Drummond