[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XACML questions for XDI TC call
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]