Should XRD allow including other XRD documents?

[Eran Hammer-Lahav]

The XRI TC is struggling with trying to balance between functionality and simplicity (of implementation). There is a long story behind it which you can read on the list archives (most recent threads) but it all boils down to this:

Should one XRD be able to include information from another XRD? For example, I have a blog at http://example.com and I want to use the services of xrd-depot.com to host my XRD documents because they offer APIs, security, and scale that I can't support myself. I can simply point my 'describedby' links to xrd-depot.com (ignoring trust issues for now) and let them handle everything.

But, what if I want to add something to my XRD that they do not support yet, like some new extension?

In another example, I have two blogs, each with its own XRD document which lists specific information about its APIs and services, but I want both to also include XRD links about my identity (OpenID, etc.). I want both XRDs to include the same subset of information. Should I be able to have both XRD include a third document?

The ability for one XRD to include another has many advantages, but it comes at a price. It is easy to take a single XRD document and load it into an XML parser and then iterate on the XML document tree. But if one document can include others, it means having to get and combine all the information from the multiple documents into a single set of information.

The question is, how important is the ability to do this? How problematic would it be if XRD did not allow for such includes? Also, how much more work do you think it is to support includes (it will involve some rules about striping the <XRD> root element and <Subject> from the included document)?

Please do not discuss technical solutions (yet / here), just the importance of the use cases and the implementation burden.

EHL

[Brett Slatkin]

Eran,

Let's learn from the mistake that causes XML external entity attacks
and not allow this.

http://www.securiteam.com/securitynews/6D0100A5PU.html

-Brett

[Blaine Cook]

I thought it already does this (in practice), via <Link> with a
rel=describedby? My take is that no, XRDs should not be able to
"include" other documents, because conceptually it doesn't make sense.
Having semantically linked documents is enough.

(also what Brett just said :) )

b.

2009/9/18 Eran Hammer-Lahav <er...@hueniverse.com>:

[Eran Hammer-Lahav]

I don't think that's an issue here because the trust model (signatures and explicit declaration of the authority chain) is going to prevent that. But that is all technical.

I want to hear about the use cases.

EHL

[Eran Hammer-Lahav]

There is nothing to require a client to go fetch another XRD document linked to from the root XRD. It is not in the processing rules. Without clear processing rules you end up with inconsistent results (which on the other thread you seems to have a big problem with).

I want to talk about the use cases, not the technical solutions. This is a question of deployment flexibility and the ability of individuals to delegate their XRD elsewhere partially or completely.

If you are going to say no, please do so in the form of an answer to the actual questions I listed. That's where we need help.

EHL

> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Blaine Cook
> Sent: Friday, September 18, 2009 2:42 AM
> To: webf...@googlegroups.com
> Subject: Re: Should XRD allow including other XRD documents?
>
>

[Brett Slatkin]

Solid use-case: getting owned when the site hosting a dependent XRD gets hacked.

On Sep 18, 2009 8:24 AM, "Eran Hammer-Lahav" <er...@hueniverse.com> wrote:


I don't think that's an issue here because the trust model (signatures and explicit declaration of the authority chain) is going to prevent that. But that is all technical.

I want to hear about the use cases.

EHL

> -----Original Message----- > From: webf...@googlegroups.com [mailto:webf...@googlegroups.com]...

[Eran Hammer-Lahav]

How is that different from the root XRD getting hacked? Or a redirect being manipulated?

 

If the linked XRD is hacked, and trust is enforced, the hacker will also need access to the private key of the SSL cert used to sign the XRD (for the hacked domain). Like anything else, if you are going to link to another XRD, you better pick reliable destinations. I think it would be safe for me to let Google manage my XRD needs, no?

 

If you are going to delegate information to any other entity, you should always keep in mind it could be hacked. This is especially true for identity related protocols. In this case, this is why we are putting so much (over 50%) effort into coming up with a trust model that will prevent such attacks.

 

The question is really if the trust model prevents the attack you describe, which I think it does (based on what the experts are telling me). So that alone is not a reason not to support these use cases. I am more interested in feedback on the need for the linking feature than on problems it might cause. The problem it will cause, we is my main concern, it make XRD libraries much more complex. The question is, is it worth it.

 

EHL

 

 

From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Brett Slatkin

Sent: Friday, September 18, 2009 8:34 AM
To: webf...@googlegroups.com

[Martin Atkins]

My gut feeling here is that for the unusual case where you want to use
an XRD hosted by someone else but make a small change to it you can
expend a little extra effort and generate an XRD that contains the
information from the target XRD, either dynamically or statically as a
one-off. (If you do the latter, it is of course your responsibility to
update it when the target changes.)

In other words, right now including other XRDs seems to me to be enough
of a corner-case that the burden should be put on the XRD host, not on
the client.

[Will Meyer]

> I am more interested
> in feedback on the need for the linking feature than on problems it might
> cause. The problem it will cause, we is my main concern, it make XRD
> libraries much more complex. The question is, is it worth it.
>

$0.015 from a lurker that's evaluating XRD for another protocol...keep
it simple for the average web dev that just wants to expose some
simple URL endpoints or parse some readable and obvious XML. Given
the ability to have Links refer to other XRD resources via
well-defined relation types, the process of pulling some document,
parsing it in some vanilla parser, then knowing at an application
protocol-layer that there is a related set of info to get via another
XRD request/parse, probably with some protocol-specific library
helping you, seems easier/better than making parsers more complicated
or requiring the client dev to pre-merge. If you believe that XRD
will become known outside of the community of those who made it not as
XRD, but simply as the format required to present metadata in other
more domain-specific protocol implementations (e.g. that webfinger
metadata format thing), that says that there will be much more use of
isolated domain-specific documents for specific protocols than general
mixing and matching and hand stewardship and programming of XRD
documents (where the includes would make more sense).

[aevans]

Use-case: Protected metadata

From http://code.google.com/p/webfinger/ :

"or even a public declaration that the email address doesn't have
public metadata, but has a pointer to an endpoint that, provided
authentication, will tell you some protected metadata, depending on
who you authenticate as."


Do all clients need to know that there may be protected metadata
available that may expose additional services,
if only so that the client can inform the user that they may need to
request access to the protected resource?

Does the fact that it requires authentication or that people may
choose to implement protected metadata using
something other than XRD push it out of scope?

Should any referenced, protected metadata (XRD, assuming proper
authentication) be included as part of the XRD for the current
subject,
or should it be treated as any other service or link that can be
published in XRD?

On Sep 18, 2:15 am, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> The XRI TC is struggling with trying to balance between functionality and simplicity (of implementation). There is a long story behind it which you can read on the list archives (most recent threads) but it all boils down to this:
>

> Should one XRD be able to include information from another XRD? For example, I have a blog athttp://example.comand I want to use the services of xrd-depot.com to host my XRD documents because they offer APIs, security, and scale that I can't support myself. I can simply point my 'describedby' links to xrd-depot.com (ignoring trust issues for now) and let them handle everything.

[Eran Hammer-Lahav]

I would argue that this use case actually cannot use such a proposed include mechanism because if you can't authenticate the included document, you have a broken or at least incomplete root document. A better approach would be to simply provider a describedby link from the root XRD which tells client "there is some more stuff over there which you can grab if you want".

EHL

[Kevin Marks]

On Thu, Sep 17, 2009 at 11:15 PM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:

The XRI TC is struggling with trying to balance between functionality and simplicity (of implementation). There is a long story behind it which you can read on the list archives (most recent threads) but it all boils down to this:

Should one XRD be able to include information from another XRD? For example, I have a blog at http://example.com and I want to use the services of xrd-depot.com to host my XRD documents because they offer APIs, security, and scale that I can't support myself. I can simply point my 'describedby' links to xrd-depot.com (ignoring trust issues for now) and let them handle everything.

But, what if I want to add something to my XRD that they do not support yet, like some new extension?

Can you not transclude this server-side yourself if need be? I think if you're geeky enough to want to do this, you're geeky enough to write the server-side code to pull in the remote one and add a line in your webserver code.

If you're not, a manual copy/paste + edit is still more likely to be got right than adding a second delagation mechanism

[Josh Patterson]

I've not studied the XRD spec recently, but in general, I'd err on the
side of simplicity to bootstrap this technology and then add
complexity in v2, etc.

Getting a technology seeded into the ecosystem is fairly hard to and
seems to be the most critical part of adoption. Ease that and I say
you stand a greater chance of growth over time.

Josh Patterson
http://jpatterson.floe.tv

On Sep 18, 2:15 am, Eran Hammer-Lahav <e...@hueniverse.com> wrote:

> The XRI TC is struggling with trying to balance between functionality and simplicity (of implementation). There is a long story behind it which you can read on the list archives (most recent threads) but it all boils down to this:
>

> Should one XRD be able to include information from another XRD? For example, I have a blog athttp://example.comand I want to use the services of xrd-depot.com to host my XRD documents because they offer APIs, security, and scale that I can't support myself. I can simply point my 'describedby' links to xrd-depot.com (ignoring trust issues for now) and let them handle everything.

[Santosh Rajan]

Exactly!

I have talked about this elsewhere on this forum.

See this thread.

http://groups.google.com/group/webfinger/browse_thread/thread/771ae21cce1c0d89

Unfortunately I am not even sure this post of mine will appear on this forum. Because I have been moderated out of here!

--
http://hi.im/santosh