XRD Provisioning Protocol - Working Draft 01

[Jared Hanson]

I just published the first draft of XRD Provisioning Protocol. I'm
posting this on the WebFinger list due to interest expressed by
members in adding links to an XRD.

The URL for this draft is:
http://xrdprovisioning.net/specs/1.0/wd01/xrd-provisioning-1.0-wd01.html

This draft is based on the session held at IIW 9, notes from which are
captured on the OASIS XRI Wiki at: http://wiki.oasis-open.org/xri/XrdOne/Provisioning

Special thanks to Will Norris for organizing that session, and to all
the people who attended. I'm hoping this draft formalizes the
protocol further, so we can continue discussions and begin
implementation. Feedback is greatly appreciated.

A Google group is open for discussion at:
http://groups.google.com/group/xrd-provisioning

Thanks.

--
Jared Hanson <http://jaredhanson.net/>

[George Fletcher]

Excellent first draft!  I have a couple comments...

1. Given that webfinger defines the access to a user's XRD as via a URI template, why is the recommendation that XRDP have a unique URL for the user's XRD? Could not the same 'lrdd' template be used?

2. In provisioning a link, should there be a way for the user to say that the <link> is "private/protected"? For example, if I keep my family photos separate from my public photos. And I want both <Link>'s provisioned in my XRD. Is there a way to restrict the family link to only those people who access the XRD in an authorized state? Or is this use case too contrived to be worthwhile? Maybe a better example would be <Link>'s representing my online health records?

3. There should probably be a security section that talks about if/when to use SSL in provisioning. Since the PUT and DELETE commands pass all the <Link> identifiers in the URL, that information is exposed. I suppose the xml:id could be used in those circumstances.

Thanks,
George

[Jared Hanson]

> 1. Given that webfinger defines the access to a user's XRD as via a URI
> template, why is the recommendation that XRDP have a unique URL for the
> user's XRD? Could not the same 'lrdd' template be used?

I'm not sure I understand your concern here. My assumption is that if
you want to provision a user's XRD, you will have already applied the
transform and fetched the XRD from the resulting URL (whatever it
is). Within the XRD fetched, the XRDP Service Endpoint will be
linked, and that is where you send provisioning requests. (That may
be the same URL that the transform resulted in, per recommendation.)

I suppose the XRDP rel could be listed in host-meta with a template,
to advertise how any resource on the host can be provisioned. Off the
top of my head, I'm not sure that is very useful.

It's also worth noting that XRDP is useful outside the scope of
WebFinger, and so shouldn't make assumptions that would make WebFinger
a dependency. Provision-able WebFingers are certainly desirable
though, and should be gotten "for free" by being XRD-based!

> 2. In provisioning a link, should there be a way for the user to say
> that the <link> is "private/protected"? For example, if I keep my family
> photos separate from my public photos. And I want both <Link>'s
> provisioned in my XRD. Is there a way to restrict the family link to
> only those people who access the XRD in an authorized state? Or is this
> use case too contrived to be worthwhile? Maybe a better example would be
> <Link>'s representing my online health records?

I think having "private" XRDs is an interesting use case, but I
haven't seen any real consensus form around best practices in this
area. The resolution specs (LRDD, host-meta) do unauthenticated HTTP
GETs to retrieve the XRD, so any link within is public knowledge
(though resolving the link may in fact require authentication). Is it
worthwhile to return additional links if the HTTP GET for the XRD
included credentials? Should "protected" XRDs be linked to from a
"public" XRD? The later case would make it easier to deal with
provisioning, as you simply wouldn't add protected links to the public
XRD.

Further discussion in this area would be helpful. Ideas? Anyone?

> 3. There should probably be a security section that talks about if/when
> to use SSL in provisioning. Since the PUT and DELETE commands pass all
> the <Link> identifiers in the URL, that information is exposed. I
> suppose the xml:id could be used in those circumstances.
>

Agreed. In the first draft I wanted to concentrate on the protocol
operations. Not to ignore security, but I expect a lot of people to
chime in on that subject who are more knowledgeable than I am.

Thanks for the feedback,
Jared