Delegation

[Joe Gregorio]

What is the proper way to do delegation with webfinger?

I own the domain bitworking.org and have the email address j...@bitworking.org,
but I really like the manageability of my Google profile, which is
for the email address joe.gr...@gmail.com. What is the right
way to delegate my webfinger to the gmail account?

Right now I serve up the following XRDD file from
http://bitworking.org/.well-known/host-meta
Note the hard coded URI template that points to the Google webfinger service:

<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
xmlns:hm='http://host-meta.net/xrd/1.0'>
<hm:Host xmlns='http://host-meta.net/xrd/1.0'>bitworking.org</hm:Host>
<Link rel='lrdd'
template='http://www.google.com/s2/webfinger/?q=acct%3Ajoe.gregorio%40gmail.com'>
<Title>Resource Descriptor</Title>
</Link>
</XRD>

DeWitt's service consumes it just fine:
http://webfingerclient-dclinton.appspot.com/lookup?identifier=j...@bitworking.org&format=web

But it does raise some questions for me. This is obviously sub-optimal
since it is
fragile in the face a changing webfinger service, which I'm fine with,
but will it be a
problem that the Subject of the final XRD document doesn't match the acct: that
initiated the lookup? What is the correct way of doing this kind of delegation?

Thanks,
-joe

[Eran Hammer-Lahav]

The delegation use case we support so far involved Gmail explicitly supporting this use case (i.e. accepting your personal domain at their webfinger endpoint, as is the case for hosted domains and OpenID). Your example breaks because the XRD you get from the gmail webfinger endpoint doesn't talk about acct: j...@bitworking.org. This gets even more problematic when a trust profile is involved and PK certificates must match the subject (or alias) and the URI you are performing discovery on.

This has been discussed both by this group and the XRD community over the past year, and the conclusion was that any good solution would make the protocol much more complex. There are a few proposals for accomplishing what you are trying to do (without the need for gmail to directly offer you this service). We rules out any XRD-level solutions for including other XRD documents or special processing rules. It was a long debate.

For example:

1. Discovery on Aliases

Your domain will serve a local XRD for your j...@bitworking.org account (you will have to host a local webfinger endpoint), which will include an alias with your gmail accout. The discovery protocol will be changed to mandate/suggest that clients then perform webfinger on the alias and use the sum of the metadata found.

2. Delegation relation type

Webfinger can define a relation type that means 'include this XRD' which will point to the gmail XRD for your account. You will still serve your own XRD on your domain pointing to gmail.

I am sure there are more way to do this, without breaking the proposed trust profiles and general architecture. The real question is if this is really a use case we want to support?

EHL

[James Walker]

I'd like to see XRD support delegation somehow... I'm not totally sure
how to make it work properly in lieu of trust signatures ... but if
it's doable, I'd love to see it happen :-)

--
James Walker :: http://walkah.net/

[Eran Hammer-Lahav]

For more background on supporting this at the XRD level, check out:

http://groups.google.com/group/webfinger/browse_thread/thread/9881b31c65836b0e

This issue is closed at the XRD level (the spec is practically done). We can still add this directly in LRDD and it is very easy to change the spec to accommodate this use case, but it comes with added client complexity (because delegation can be recursive).

[Brad Fitzpatrick]

Could including another site's XRD just be including an acct: "me" link?

For instance, on br...@danga.com's XRD I could have:

    <Link rel='describedby' href='acct:brad...@gmail.com' type='application/xrd+xml' />

?

... which effectively is an include?  Then best practice for resolvers is keep expanding, up to 'n' hops?  (where n is maybe a SHOULD of ~3 and a MUST of 1?)

[Eran Hammer-Lahav]

Yeah, that’s option #2.

 

As for your specific example, that doesn’t work. If you use ‘describedby’ it should point to the XRD itself (describing your gmail account). If you want to point to the other identified (i.e. the alias), you need to come up with another relation type that means ‘for more information perform webfinger on this other identifier’ (really, it is perform LRDD because it might not be an acct URI).

 

If you point to the other XRD itself, the relation is more like an ‘include’ or ‘replace’ (both are valid options with their own complexities). I wouldn’t use ‘describedby’ because it is not well defined in terms of protocol flow and is used in ways that should not imply an include. Option #1 is more appropriate (following aliases).

 

Do you want an include pointing to the other XRD or do you want a “see-also” pointing to the other identifier?

 

EHL

 

 

From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Brad Fitzpatrick
Sent: Friday, February 12, 2010 7:43 AM
To: webf...@googlegroups.com
Subject: Re: Delegation

 

Could including another site's XRD just be including an acct: "me" link?

[Will Norris]

On Feb 11, 2010, at 11:17 PM, Eran Hammer-Lahav wrote:

> The delegation use case we support so far involved Gmail explicitly supporting this use case (i.e. accepting your personal domain at their webfinger endpoint, as is the case for hosted domains and OpenID). Your example breaks because the XRD you get from the gmail webfinger endpoint doesn't talk about acct: j...@bitworking.org. This gets even more problematic when a trust profile is involved and PK certificates must match the subject (or alias) and the URI you are performing discovery on.

I think this is the same use case Breno and I discussed yesterday when hashing out the X.509 trust profile for XRD. We're effectively looking at bringing back the "next authority" concept to handle trust delegation. That would allow the host-meta for bitworking.org to declare that "id.google.com" is authorized to sign XRD documents. That of course still assumes that said XRD document would include a <Subject> or <Alias> for "j...@bitworking.org". Additionally, it still means that the host-meta document for bitworking.org would need to be signed with a certificate issued to "bitworking.org"... there's really no way to delegate that that makes any kind of sense.

-will

[Brad Fitzpatrick]

I think personally I'd like an 'include' more than a 'replace', as I'd like to blend in my own services.  Otoh, I hope I'd be able to override things from the place I'm including.

Maybe I don't like Google's implementation of X, or company Y does it better, so I want to include brad...@gmail.com's XRD for br...@danga.com, but choose a different X endpoint.  Whatever we do, I just want the resolution priority to be well-defined.  (SRV-style weights?  declaration order matters?)

[DeWitt Clinton]

I'm worried about the n^m-hops case myself.  For a service that will be often used in as synchronous environment, we're already looking at a minimum of 3 fetch-and-parses to retrieve what the client is likely interested in.  If we need to compute the transitive closure of all n included resource descriptions and _their_ m included resources, then clients aren't really going to be able to handle it in a predicable amount of time, and will be forced to moved to an asynchronous architecture.

For example, if we did support n^m-includes, then my little appengine based client would need to switch from the current synchronous fetch model to an asynchronous request queue model with a poll/hanging get down to the client.  That's massive amount of work to just to support a relatively rare (but very useful) use case.  In practice many clients wouldn't support it or would timeout trying to support it, breaking webfinger for those who want to delegate.

I realize I'm not offering a solution, just mentioning a potential problem if we want to keep things simple on the client (which I believe we do).

-DeWitt

[Brad Fitzpatrick]

Brett and I could help you do async HTTP fetches on App Engine... we did it in the PSHB hub implementation.  :-)

But seriously:  let's do what's right, make a big conformance test suite page where we can highlight / embarrass buggy client implementations, and then we can collect and highlight good, fast, async, conforming, open source client implementations in the top languages.  

I personally think delegation is important enough to make clients a bit harder.... I'm even willing to write all those clients if need be, but fortunately other people can write PHP, Haskell, and Erlang better than me.  :-)

But yes, we should bound the expansion, and probably pretty shallow.

[James Walker]

I think - with a good, solid suite of libraries - we can afford a bit
of extra complexity. I'm happy to help on the PHP front (as we've
started in on a bunch of this already for status.net) ... sadly,
erlang makes my eyes bleed.

One complication as we increase the # of potential hops per lookup is
there's no (afaict) concept of TTL for any of this stuff - so I assume
every time we want to grab any of the info about a webfinger - we're
going through all of the hops. It'd be nice to have a reliable
indicator for caching some of the results.

You know... while we're adding complexity ;-)

--
James Walker :: http://walkah.net/

[Will Norris]

XRD documents have an <Expires> element for exactly this purpose.

http://tools.oasis-open.org/version-control/svn/xri/xrd/1.0/drafts/wd13/xrd-1.0-wd13.html#element.expires

-will

[Eran Hammer-Lahav]

XRD used to have a priority attribute just like DNS records which was removed and replaced with simple document ordering. Priorities across documents should be done in a consistent way, either by implementing a real include (in-place, insert), or by processing everything in one XRD and then processing other linked XRDs in the order they are linked.

 

The first option (in-place expansion) is better for XRD authors but more work for clients (because they have to change the default behavior of XML parsers to load half a document, then go load another document into it, then go back).

 

The second means the first XRD overrides or comes before *anything* in the included XRD.

[Brad Fitzpatrick]

Can't we just use HTTP?  Are we really going to be using another transport?

[Eran Hammer-Lahav]

You can use both or either one. XRD has this because it is explicitly not bound to HTTP, but for webfinger you can use whatever works for you.

 

EHL

 

From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Brad Fitzpatrick
Sent: Friday, February 12, 2010 8:46 AM
To: webf...@googlegroups.com
Subject: Re: Delegation

 

Can't we just use HTTP?  Are we really going to be using another transport?

[James Walker]

Oh blargh. My bad... I must've skimmed right past that. Nevermind :-)

[James Walker]

You mean via an Expires header? I'd be fine with either, but right now
it doesn't look like either is in place... (on gmail.com at least).

The <Expires/> element in XRD though does keep it transport neutral...
you know, for XRD over XMPP ;-)

[Brad Fitzpatrick]

Or the Unicorn Pony Transport Protocol, for that matter.  :-)

[James Walker]

I'm not familiar with that one... but I sure wouldn't want to exclude
rfc1149 implementations from using XRD.

[John Panzer]

Given that people are going to be using HTTP(s) to retrieve this stuff, and libraries and proxies implement HTTP caching based on standard headers, I don't think there's any question about using HTTP caching; of course it will, in fact the spec needs to assume that it will happen because it's the default.

RFC1149 is a bird of a different feather.

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Eran Hammer-Lahav]

And this work should not worry about it. Implementing HTTP properly is not our business.

 

EHL

 

From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of John Panzer
Sent: Friday, February 12, 2010 10:11 AM
To: webf...@googlegroups.com
Subject: Re: Delegation

 

Given that people are going to be using HTTP(s) to retrieve this stuff, and libraries and proxies implement HTTP caching based on standard headers, I don't think there's any question about using HTTP caching; of course it will, in fact the spec needs to assume that it will happen because it's the default.

[John Panzer]

Right; but, you should be aware that setting the XRD specific <Expires> to something that conflicts with the HTTP caching directives may not do what you want.  E.g., if HTTP says to cache for 86400 seconds, but Expires is set to 10s, the XRD processing layer may honor that but the underlying HTTP library and proxy caches will not.  Alternatively, you'd need to give advice to people as to how to try to override the HTTP layer caching in this case, if you want <Expires> to actually work when using HTTP.

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Will Norris]

which is why we added the text to the latest draft:

> If present, any cache expiration date specified by the transport
> protocol SHOULD NOT be later than the time instant indicated by the
> <Expires> element.

I don't know how the spec could instruct people to override the HTTP
layer caching... that's specific to the HTTP stack the application is
using.

On Feb 12, 2010, at 10:27 AM, John Panzer wrote:

> Right; but, you should be aware that setting the XRD specific
> <Expires> to
> something that conflicts with the HTTP caching directives may not do
> what
> you want. E.g., if HTTP says to cache for 86400 seconds, but
> Expires is set
> to 10s, the XRD processing layer may honor that but the underlying
> HTTP
> library and proxy caches will not. Alternatively, you'd need to
> give advice
> to people as to how to try to override the HTTP layer caching in
> this case,
> if you want <Expires> to actually work when using HTTP.
>
> --
> John Panzer / Google

> jpa...@google.com / abstractioneer.org <http://www.abstractioneer.org/

> > /
> @jpanzer
>
>
>
> On Fri, Feb 12, 2010 at 10:13 AM, Eran Hammer-Lahav <er...@hueniverse.com
> >wrote:
>
>> And this work should not worry about it. Implementing HTTP properly
>> is not
>> our business.
>>
>>
>>
>> EHL
>>
>>
>>

>> *From:* webf...@googlegroups.com
>> [mailto:webf...@googlegroups.com] *On
>> Behalf Of *John Panzer
>> *Sent:* Friday, February 12, 2010 10:11 AM
>>
>> *To:* webf...@googlegroups.com
>> *Subject:* Re: Delegation

>>
>>
>>
>> Given that people are going to be using HTTP(s) to retrieve this
>> stuff, and
>> libraries and proxies implement HTTP caching based on standard
>> headers, I
>> don't think there's any question about using HTTP caching; of
>> course it
>> will, in fact the spec needs to assume that it will happen because
>> it's the
>> default.
>>
>>
>>
>> RFC1149 is a bird of a different feather.
>>
>> --
>> John Panzer / Google

>> jpa...@google.com / abstractioneer.org <http://www.abstractioneer.org/

>>>>>>>>>> <Link rel='describedby' href='acct:brad...@gmail.com<acct%3Abra...@gmail.com

[Joe Gregorio]

On Fri, Feb 12, 2010 at 2:17 AM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
> The delegation use case we support so far involved Gmail explicitly supporting this use case
> (i.e. accepting your personal domain at their webfinger endpoint, as is the case for hosted
> domains and OpenID). Your example breaks because the XRD you get from the gmail
> webfinger endpoint doesn't talk about acct: j...@bitworking.org.

So checking the Subject matches on the final XRD document is a MUST in
some specification?

> This gets even more problematic when a trust profile is involved and PK certificates must
> match the subject (or alias) and the URI you are performing discovery on.

I'm not going to spend much time talking about the PK cert aspect. I
will be deeply impressed
if it ever gets general usage, as it would be the first widely
deployed signed XML in the history
of the internet.

Thanks,
-joe

[Will Norris]

On Feb 12, 2010, at 11:08 AM, Joe Gregorio wrote:

> On Fri, Feb 12, 2010 at 2:17 AM, Eran Hammer-Lahav <er...@hueniverse.com
> > wrote:
>> The delegation use case we support so far involved Gmail explicitly
>> supporting this use case
>> (i.e. accepting your personal domain at their webfinger endpoint,
>> as is the case for hosted
>> domains and OpenID). Your example breaks because the XRD you get
>> from the gmail
>> webfinger endpoint doesn't talk about acct: j...@bitworking.org.
>
> So checking the Subject matches on the final XRD document is a MUST in
> some specification?

Yes, in the trust profile.

[John Panzer]

OK, though some environments may not be able to comply with this very effectively (thus the SHOULD), so clients still have to know what to do when they conflict.

xmlns='http://host-meta.net/xrd/1.0'>bitworking.org</hm:Host>
<Link rel='lrdd'



template='

[Blaine Cook]

On 12 February 2010 19:08, Joe Gregorio <j...@bitworking.org> wrote:
> I'm not going to spend much time talking about the PK cert aspect. I
> will be deeply impressed if it ever gets general usage, as it would be the first widely
> deployed signed XML in the history of the internet.

+1.

As far as Joe's specific use case is concerned, I think inclusion
(i.e., Joe's initial approach) needs to work, since that's what people
will do in practice (c.f., .forward files). Redirects would be nice,
because I suspect that's intuitive option #2 (c.f., MX records).

I'm not concerned about service providers needing to recognize
secondary / alternate domains. This is something we have vast
experience with on the internet (HTTP virtual hosting and SMTP relay
domains spring to mind).

b.

[Eran Hammer-Lahav]

On Feb 12, 2010, at 11:08, "Joe Gregorio" <j...@bitworking.org> wrote:

> On Fri, Feb 12, 2010 at 2:17 AM, Eran Hammer-Lahav <er...@hueniverse.com
> > wrote:
>> The delegation use case we support so far involved Gmail explicitly
>> supporting this use case
>> (i.e. accepting your personal domain at their webfinger endpoint,
>> as is the case for hosted
>> domains and OpenID). Your example breaks because the XRD you get
>> from the gmail
>> webfinger endpoint doesn't talk about acct: j...@bitworking.org.
>
> So checking the Subject matches on the final XRD document is a MUST in
> some specification?

This is a trust profile issue. And it should also include Aliases.

>> This gets even more problematic when a trust profile is involved
>> and PK certificates must
>> match the subject (or alias) and the URI you are performing
>> discovery on.
>
> I'm not going to spend much time talking about the PK cert aspect. I
> will be deeply impressed
> if it ever gets general usage, as it would be the first widely
> deployed signed XML in the history
> of the internet.

I am not arguing with you, but there are use case that require the
ability to verify the authority of the document. Either way, we can
solve the use case but just need to decide what is acceptable for
added client complexity.

EHL

>
> Thanks,
> -joe

[Pelle Wessman]

Do I understand it correctly that you're suggesting direct reference of another XRD as one way of solving delegation? Not finding out the XRD through the combination of an host-meta template and an acct-uri? If so - wouldn't it be a problem if the XRD moves and the template changes? Just referencing the acct-uri would make it more complex to resolve the data - but would proof it from any future template changes?

/ Pelle

[Eran Hammer-Lahav]

I wasn’t suggesting one way over the other, just that the relation type must match semantically, what it is pointing to.

 

EHL

[Kaliya *]

One way to answer questions about delegation would be to ask Drummond Reed (who is not on this list, I checked.).