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


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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

Subject: RE: [xdi] Re: Proposed XDI TC Charter Revision v1

Title: RE: [xdi] Re: Proposed XDI TC Charter Revision v1

--My apologies if this is double posted, I'm having a problem with our webmail.--

I've also always considered link contracts to be the most important aspect of XDI, and the best value added to the XRI spec.

I'd suggest that rather than re-inventing a policy language and framework we look at another OASIS spec, XACML. I think that the spec as it is may fit our needs, and if not the spec is very extensible and so we can add as needed to get what we want, similar to what Toktar et al. did  for using XACML to policy control RSVP (see thrid link below). Here are some links on XACML:


If consensus is to explore XACML further I suggest we contact Rebeka Metz (metz_rebekah@bah.com) , one of the very active personnel on the XACML TC, and someone who I believe we have consulted before.

Whether we go with XACML or another policy language we need to determine how to tie it to the resource accessed. My first thought was one of the following, in order from what I thought least elegant to most:
a. A policy element that's a child of the resource controlled
b. a resource child of the resource controlled with a special $ word relative XRI
c. a resource child of the resource controlled with a special + relative xri as defined by the service dictionary

But then I realized that the link contract is not an attribute of the resource being controlled, but rather an attribute of the arc between the resource being accessed and the entity doing the accessing, as identified by their i-name or better yet i-number.

With that in mind I'd like to toss out the following idea:
A +word as defined by the XDI Service Dictionary deliverable that sits at the root of each XRI authority, when that authority offers the XDI local access service. A rough example of the XRI used to access the policy resource that controls xri://=bob accessing xri://@communitivity*foo*bar/baz*bak/bok would be xri://@communitivity*foo*bar*(@xdi*(+policy))/(=bob)/baz*bak/bok
which would return an XDI document containing the policy information in the data element of the root resource. You could even use synonyms to have .../(=bob)/... go to xri://@communitivity*foo*bar*(@xdi*(+policy))/(@communitivity*groups/longtimeusers)/baz*bak/bok

You'd need to control access to these resources as well, since most sites won't want their policy publicly available. This has the added benefit of not being tied to the XDI schema in any way other than that an XDI resource has a single data element.

Unfortunately I am in training all day tomorrow, so unless I can convince everyone to break at the right time I won't be able to join the call. A well-timed lunch break is possible though as I think the call is at noon EST, but will have to check. If not, my apologies in advance.

Thanks Victor, great points!

-----Original Message-----
From: Victor Grey [mailto:victor@idcommons.org]
Sent: Tue 11/8/2005 1:49 PM
To: 'XDI TC'
Subject: [xdi] Re: Proposed XDI TC Charter Revision v1

There is a real disconnect for me in the current proposed XDI charter.
As an implementer, the most important part of XDI to me is the concept
of "link contracts". These, as the proposed charter states, are to
support features including those to "govern authorization, access
control, usage control, synchronization, and rights management."
However, the list of deliverables does not even mention link contracts!

What's more, the proposed charter says "As a data sharing service, XDI
is intended to be very simple and generalized." The one example I have
seen so far of an attempt to implement anything like XDI is, imho,
anything but simple and generalized. What's more, it doesn't include
any actual implementation of link contracts.

Link contracts are the one thing that I would need to try to do any
useful implementation, even experimentally. I think that the lack of
work and attention to this aspect has been a huge drag on progress.
Therefore I would like to propose something rather radical -- that we
stand our approach to XDI on its head, and start from the link
contracts end, rather than the schema end. A link contract, in my
conception, would look quite a bit like an XRID (perhaps an XDID?), and
would gain from our recent experience with crafting an XRID spec that
is simple enough that it may actually be useful to non-XRI

An XDID would be a (simple as possible, all elements optional) schema
capable of describing authorization, access control, usage control,
synchronization, and rights management. It would be returned in
response to a data query, similar to the way an XRID is returned in
response to an authority query. It would contain a section analogous to
the <service> section of an XRID, but would instead be a
<serialization> section, where the available data structures could be
discovered. This would allow data in -any- XML format (and any other
format really -- anything serializable) to be addressed with XRI and
controlled with XDI.

If there is a demand for the uber-XML format that the XDI TC has been
struggling with for two years, work on this could continue, but
progress and implementation experience would not have to be held
hostage to that ambitious undertaking.


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