google webfinger prototype updated...

[Brad Fitzpatrick]

Update...

If you have a Google Profile with an interest of "webfingeralpha" (one word) and a public username, then you now have a WebFinger document.  (using the interest substring as an on-switch is kinda a hack, but whatever... :-))

Remember that WebFinger operates not on email addresses but on email-like identifiers (something@somewhere), so the q= parameter in the exampel URLs below is an email-like thing, not necessarily an email address.  So it works even for Google profiles that are associated with no...@gmail.com Google accounts and have turned on public usernames.  (because in Google's case, our profiles' public usernames are in the same namespace as gmail.com or googlemail.com usernames....)

For instance,

http://www.google.com/profiles/nottageemail

http://www.google.com/s2/webfinger/?q=nottag...@gmail.com

http://www.google.com/s2/webfinger/?q=nottag...@gmail.com&fmt=foo

http://www.google.com/profiles/bradfitz

http://www.google.com/s2/webfinger/?q=brad...@gmail.com

http://www.google.com/s2/webfinger/?q=brad...@gmail.com&fmt=foo

Next up:  some format besides "foo".  Maybe FOAF or some existing JSON format?

Also, I should declare our Portable Contacts API[1] service endpoint to all user's XRD files too.  It's already in our XRDS file[2].

(I figure I can keep working on this stuff in parallel with everybody figuring out exact details of the WebFinger XRD stuff...)

- Brad

[1] http://code.google.com/apis/contacts/docs/poco/1.0/developers_guide.html

[2] http://www.google.com/xrds/xrds.xml

[Brett Slatkin]

Yay milestone!

[Mason Lee]

Is the 'fmt' param here a way to access documents other than XRD, or
is it shorthand to grab a specific service out of XRD?

On Aug 17, 4:12 pm, Brad Fitzpatrick <bradf...@google.com> wrote:
> Update...
>
> If you have a Google Profile with an interest of "webfingeralpha" (one word)
> and a public username, then you now have a WebFinger document.  (using the
> interest substring as an on-switch is kinda a hack, but whatever... :-))
>
> Remember that WebFinger operates not on email addresses but on email-like
> identifiers (something@somewhere), so the q= parameter in the exampel URLs
> below is an email-like thing, not necessarily an email address.  So it works

> even for Google profiles that are associated with n...@gmail.com Google

> accounts and have turned on public usernames.  (because in Google's case,
> our profiles' public usernames are in the same namespace as gmail.com or
> googlemail.com usernames....)
>
> For instance,
>
> http://www.google.com/profiles/nottageemail

> http://www.google.com/s2/webfinger/?q=nottageem...@gmail.com
> http://www.google.com/s2/webfinger/?q=nottageem...@gmail.com&fmt=foohttp://www.google.com/profiles/bradfitz
> http://www.google.com/s2/webfinger/?q=bradf...@gmail.com
> http://www.google.com/s2/webfinger/?q=bradf...@gmail.com&fmt=foo

[Brad Fitzpatrick]

The former. But it's just a temporary hack.

Any actual implementations of useful formats (say, FOAF) will go on prettier URLs later.  By during public prototyping, it'll be on the ugliest URL possible like &fmt=foaf.

[Markus Thielmann]

Sorry if this sounds dumb, but I still don't get it.

"Format" sounds like accessing the same content in a different markup,
while FOAF essentially offers different/additional content. Could you
clarify that a bit? I was trying to figure it out for the last days,
but I'm still unsure what to expect.

Additional to that, I'm unsure if Webfinger intends to offer some kind
of authorization/identification or will leave that up to other
services announced through Webfinger? If Webfinger doesn't offer
secure access, I don't see the value of offering FOAF directly through
Webfinger instead of just linking to the FOAF file.

I'd be really happy if you could give me some insight of the idea
behind "fmt".

[Brad Fitzpatrick]

Ignore the seeming-similarity in the URLs.  I was just being lazy.  "fmt" or FOAF aren't part of WebFinger.  Just added FOAF as a demo and the URL just happened to have fmt on it because it was an easy way of not adding a separate HTTP handler.

[Martin Atkins]

On Aug 17, 4:12 pm, Brad Fitzpatrick <bradf...@google.com> wrote:

> Update...
>
> If you have a Google Profile with an interest of "webfingeralpha" (one word)
> and a public username, then you now have a WebFinger document.  (using the
> interest substring as an on-switch is kinda a hack, but whatever... :-))
>
> Remember that WebFinger operates not on email addresses but on email-like
> identifiers (something@somewhere), so the q= parameter in the exampel URLs
> below is an email-like thing, not necessarily an email address.  So it works

> even for Google profiles that are associated with n...@gmail.com Google

> accounts and have turned on public usernames.  (because in Google's case,
> our profiles' public usernames are in the same namespace as gmail.com or
> googlemail.com usernames....)
>

I notice that my non-gmail email address associated with my Google
Account doesn't return an XRD response following the pattern in your
examples. It just returns the string "Let's do this!". Not that I
really know what I'd want it to do in that case anyway; I have two
accounts at Google with that email address for one thing, so it's not
clear which one it would use.

I've also webfinger-enabled the email-like identifier corresponding to
the email address I'm posting this message from. However, just to mix
things up a little I've declared my domain's XRD in DNS:

$ host -t TXT degeneration.co.uk
degeneration.co.uk descriptive text "v=xrd1 url=http://
martin.atkins.me.uk/webfinger/degeneration.co.uk.xml"
(though I don't think my change has taken effect on the public servers
that do my DNS yet, so you probably can't see this record at the time
of writing)

Are there any consumer-side implementations of this yet? (Or even just
implementations of XRD parsing; the additional lookups in front of
that ought to be trival to bolt on.)

[Brad Fitzpatrick]

Dewitt wrote one:  (web and command-line)

http://webfingerclient-dclinton.appspot.com/

It doesn't do the DNS lookup I don't think.  Also, I think we're all learning towards using SRV instead of TXT for the optional DNS part.  (optional for publishers, required for clients...)

We need to add a DNS lookup capability to App Engine, too.

[DeWitt Clinton]

Yeah, that particular hosted client won't be able to do DNS+SRV because it is App Engine based.  If DNS is required, then this won't ever be a compliant client, I'm afraid.

The command line version could, so I'll add that.  Has anyone written down what the record will look like yet?

-DeWitt

[Brad Fitzpatrick]

On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dcli...@gmail.com> wrote:

Yeah, that particular hosted client won't be able to do DNS+SRV because it is App Engine based.  If DNS is required, then this won't ever be a compliant client, I'm afraid.

The command line version could, so I'll add that.  Has anyone written down what the record will look like yet?

I think we all mostly agreed it'd be a SRV record for "_tcp" service "_hostmeta".  Then what you get back is a hostname / port number from srv, and use that instead of the original host and implied port 80 if you get a SRV answer.  (and still fetch the path /.well-known/host-meta)

Test your DNS lookup code fetching e.g.:

$ dig -t srv _xmpp-server._tcp.gmail.com

;; ANSWER SECTION:

_xmpp-server._tcp.gmail.com. 86400 IN SRV 5 0 5269 xmpp-server.l.google.com.

_xmpp-server._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server1.l.google.com.

_xmpp-server._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server2.l.google.com.

_xmpp-server._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server3.l.google.com.

_xmpp-server._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server4.l.google.com.

Where the 5269 is the port, and the hostname you'd connect to is in the last column.

[Blaine Cook]

Can we drop the DNS discussion from the webfinger side of things? It
seems like it's something that needs to be nailed down in XRD, and the
security implications of delegating openid lookups from DNS are
problematic at best, so probably not something we can solve here.

Given that we've tried to limit discussing XRD here as much as
possible, what else needs to be specified in order to make this stuff
work? I haven't been following the XRD discussions, but is that where
the work needs to happen?

b.

2009/8/31 Brad Fitzpatrick <br...@danga.com>:

[Martin Atkins]

Brad Fitzpatrick wrote:
> On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dcli...@gmail.com> wrote:
>
>> Yeah, that particular hosted client won't be able to do DNS+SRV because it
>> is App Engine based. If DNS is required, then this won't ever be a
>> compliant client, I'm afraid.
>> The command line version could, so I'll add that. Has anyone written down
>> what the record will look like yet?
>>

If app engine can't do it then that seems like a show-stopper for
DNS-based discovery.

>
> I think we all mostly agreed it'd be a SRV record for "_tcp" service
> "_hostmeta". Then what you get back is a hostname / port number from srv,
> and use that instead of the original host and implied port 80 if you get a
> SRV answer. (and still fetch the path /.well-known/host-meta)
>

Requiring the path to still be /.well-known/host-meta seems to me to
defeat the point of using DNS a little.

Do you expect that the site at the other end would use the Host header
to decide what to serve? While that could certainly work, it complicates
my setup considerably compared to just adding a TXT record with a URL in
it. (I guess I'd need to set up a web server on the nominated
server/port that knows to expect a Host: degeneration.co.uk, rather than
just use the site I already have.)

SRV doesn't seem to fit here. If we're going to use esoteric record
types (i.e. not the A, CNAME or TXT that are generally supported by DNS
services) then we might as well use NAPTR, which is a better fit here
since its result is a URI.

However, I'd much rather just use TXT. Sure, it's not the cleanest thing
in the world, but it's the thing that's most readily available to use.
Is there a pragmatic reason to use SRV over TXT?

[Brad Fitzpatrick]

On Sun, Aug 30, 2009 at 6:31 PM, Martin Atkins <ma...@degeneration.co.uk> wrote:

Brad Fitzpatrick wrote:

On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dcli...@gmail.com> wrote:

Yeah, that particular hosted client won't be able to do DNS+SRV because it
is App Engine based.  If DNS is required, then this won't ever be a
compliant client, I'm afraid.
The command line version could, so I'll add that.  Has anyone written down
what the record will look like yet?

If app engine can't do it then that seems like a show-stopper for DNS-based discovery.

We'll just fix App Engine.

But Blaine's right --- let's leave the details to the XRD group.  For now, the answer for WebFinger is to use an XRD library.  (once they exist & XRD discovery is fully defined...)

[Will Norris]

just in case people are interested in following up on this discussion,
it won't actually be happening in the XRI TC. XRD 1.0 defines the XML
format of the document and basic rules for processing the document.
It says nothing about how you obtain the XRD document for a given
resource. That will be defined in the work Eran is doing in IETF, as
well as by protocols that make use of XRD (ie. OpenID Discovery 2.x
can choose to define what methods consumers should use to discover the
XRD for an OpenID).

So for those that want to continue following this discussion, look to https://www.ietf.org/mailman/listinfo/apps-discuss

-will

[DeWitt Clinton]

Thanks for the pointer to dnspython.  Looks like it will work perfectly in environments that can access raw sockets.  I'll update the test client to work with SRV lookup and take an educated guess for now about what the exact record format will look like.

Will the IETF apps-discuss list also be the right place to discuss possible HTML <link> and HTTP Link header discovery of XRD documents?  Is that even still on the table?

-DeWitt

[DeWitt Clinton]

Agreed.  I only brought up XRD here at all because I can't subscribe or post to the OASIS list, which is frustrating as hell, even if I acknowledge their rationale.  Anyway, discovery is the point of webfinger, so this group needs to get it right, not just hope that someone else gets it right.

-DeWitt

[Will Norris]

On Aug 30, 2009, at 7:44 PM, DeWitt Clinton wrote:

> Will the IETF apps-discuss list also be the right place to discuss
> possible
> HTML <link> and HTTP Link header discovery of XRD documents? Is
> that even
> still on the table?

# short answer
HTTP Link Header and HTML <link> are most certainly still part of the
proposed discovery methods for XRD.

# slightly longer answer
Exactly where different pieces of the puzzle are defined has changed a
bit, but the relevant drafts are still:

1) http://tools.ietf.org/html/draft-nottingham-http-link-header
2) http://tools.ietf.org/html/draft-nottingham-site-meta

And to a somewhat lesser degree:
3) http://tools.ietf.org/html/draft-hammer-discovery

Most of the content in #3 has actually been rolled up into #1.
Additionally, since #2 has actually become the definition of the .well-
known location, there will still need to be another document which
actually registers host-meta in that location. Since host-meta will
use XRD for its file format, Eran is waiting on a committee draft of
XRD 1.0 to reference.

[Eran Hammer-Lahav]

First, you (DeWitt) can join the XRI list as a Google employee. We already have three other people from Google there which means Google already agreed to the charter. Anyone else who would like to join the TC can ping me. We have found ways to accommodate pretty much everyone who asked.

 

Second, yes, it is very important we get discovery right. The question of using other links (HTTP, HTML) is what LRDD is trying to solve, but I am not sure where that spec is going. I am working on a new draft and when ready (I plan on this week), I will ping this list and will indicate where it will be discussed.

 

EHL

[Martin Atkins]

Blaine Cook wrote:
> Can we drop the DNS discussion from the webfinger side of things? It
> seems like it's something that needs to be nailed down in XRD, and the
> security implications of delegating openid lookups from DNS are
> problematic at best, so probably not something we can solve here.
>
> Given that we've tried to limit discussing XRD here as much as
> possible, what else needs to be specified in order to make this stuff
> work? I haven't been following the XRD discussions, but is that where
> the work needs to happen?
>

I'm all for avoiding scope bleed between these various groups, but if
this group isn't discussing how to do discovery on an acct: URL then
what exactly *is* the scope of WebFinger?

I'm having a lot of trouble figuring out which of these bajillion
mailing lists I should actually be following. It feels like right now
things are a little *too* divided, with lots of related work getting
spread too thinly over various different forums rather than us all
working together in one place.

[Brad Fitzpatrick]

On Mon, Aug 31, 2009 at 11:11 AM, Martin Atkins <ma...@degeneration.co.uk> wrote:

Blaine Cook wrote:

Can we drop the DNS discussion from the webfinger side of things? It
seems like it's something that needs to be nailed down in XRD, and the
security implications of delegating openid lookups from DNS are
problematic at best, so probably not something we can solve here.

Given that we've tried to limit discussing XRD here as much as
possible, what else needs to be specified in order to make this stuff
work? I haven't been following the XRD discussions, but is that where
the work needs to happen?

I'm all for avoiding scope bleed between these various groups, but if this group isn't discussing how to do discovery on an acct: URL then what exactly *is* the scope of WebFinger?

Scope of WebFinger (and this mailing list) is:

1) how to take an email-like identifier and get back a readable document.  namely, the rules for email-like, and doing XRD discovery on the email-like host part's site, then looking for webinfo capability in the host's XRD document, then translating the URITemplate to get the user acct's XRD document.

2) all the possible service Rel types that we could/should use for various things.

I think 1) is largely all defined now.  It's probably more time to be talking about 2.

I'm having a lot of trouble figuring out which of these bajillion mailing lists I should actually be following. It feels like right now things are a little *too* divided, with lots of related work getting spread too thinly over various different forums rather than us all working together in one place.

I think there are just ~2 lists?

[Eran Hammer-Lahav]

It's not too bad.

WebFinger uses XRD, Link, and host-meta.

XRD is being finalized in the OASIS XRI TC.
Link is an IETF spec which is also in its final phase and discussed on the HTTP list (ietf-h...@w3.org).
Host-meta is currently defined in LRDD (my draft) which is pending a major rewrite and will be discussed on the IETF Apps list.

WebFinger is just an application written on top of these three specs, but the key will be figuring out what data to put in the XRD.

EHL

> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Martin Atkins
> Sent: Monday, August 31, 2009 11:12 AM
> To: webf...@googlegroups.com
> Subject: Re: google webfinger prototype updated...
>
>

[Christian Scholz]

Hi!

Brad Fitzpatrick schrieb:
> [...]

> Scope of WebFinger (and this mailing list) is:
>
> 1) how to take an email-like identifier and get back a readable
> document. namely, the rules for email-like, and doing XRD discovery
> on the email-like host part's site, then looking for webinfo
> capability in the host's XRD document, then translating the
> URITemplate to get the user acct's XRD document.
>
> 2) all the possible service Rel types that we could/should use for
> various things.
>
> I think 1) is largely all defined now. It's probably more time to be
> talking about 2.

Do I assume correctly that the idea is basically the one of a service
catalogue for a user which holds a list of all the services he has
access to a service and/or data?
E.g. a list of all my profiles, contact lists, photos, activity stream
services etc. so that a site I sign up to can quickly retrieve that data
without me typing it in again (plus posting to services)?

If so I wonder if the idea is then to just bind it to an email like
identifier or also factor this out for URL based identifiers such as
OpenIDs?

cheers,

Christian

[Martin Atkins]

Brad Fitzpatrick wrote:
>
> 1) how to take an email-like identifier and get back a readable
> document. namely, the rules for email-like, and doing XRD discovery on
> the email-like host part's site, then looking for webinfo capability in
> the host's XRD document, then translating the URITemplate to get the
> user acct's XRD document.
>

Okay, so this looks like:

* Take the domain part.
* Do discovery on it as defined by the XRD spec and find the domain's
own XRD document. (though I'm sure someone said elsewhere that the XRD
spec is just about the format and not about the discovery of the document.)
* Get the WebFinger template out of the discovered XRD and substitute
the account identifier into it and request the result to get another XRD.

So it seems like webfinger has two direct dependencies:

* How to find the XRD for a given host. (the host-meta spec?)
* How to process an XRD. (the XRD spec)

...and what it provides in addition to what's provided by those
dependencies is the extra step of how to discover the XRD of a
particular account within an authority, where host-meta only describes
how to discover the XRD for the authority itself.

Does that seem right?

If so, I agree that the DNS discovery thing belongs in the host-meta
spec and not in the webfinger spec. So I guess that's to be discussed on
the IETF apps list.

(Still trying to figure out what the relationship is between all of
these specs. Sorry if I'm just being slow.)

[Eran Hammer-Lahav]

Exactly.

If you have feedback about XRD, send it over to the XRI TC (links somewhere in the archive). I will post here as soon as there is a new draft of host-meta and will let you know where to discuss it. If it makes your life easier, just ping me directly about all of it...

EHL

> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Martin Atkins
> Sent: Monday, August 31, 2009 2:16 PM
> To: webf...@googlegroups.com
> Subject: Re: google webfinger prototype updated...
>
>

[Christian M. Jensen]

I have feedback - can you dig up the link?

[Eran Hammer-Lahav]

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri#feedback