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....)
On Mon, Aug 17, 2009 at 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=foo > http://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 > 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
> 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....)
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.
On Mon, Aug 17, 2009 at 5:00 PM, Mason Lee <mason....@gmail.com> wrote:
> 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....)
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".
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.
On Sat, Aug 29, 2009 at 12:25 PM, Markus Thielmann <m...@markusthielmann.com
> 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".
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.)
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.
On Sun, Aug 30, 2009 at 12:40 AM, Martin Atkins <m...@degeneration.co.uk>wrote:
> 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.)
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
On Sun, Aug 30, 2009 at 2:47 PM, Brad Fitzpatrick <bradf...@google.com>wrote:
> 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.
> On Sun, Aug 30, 2009 at 12:40 AM, Martin Atkins <m...@degeneration.co.uk>wrote:
>> 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.comor >> > 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.)
On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dclin...@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.
>> 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.
>> On Sun, Aug 30, 2009 at 12:40 AM, Martin Atkins <m...@degeneration.co.uk>wrote:
>>> 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.comGoogle >>> > accounts and have turned on public usernames. (because in Google's >>> case, >>> > our profiles' public usernames are in the same namespace as gmail.comor >>> > 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.)
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?
> On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dclin...@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.
>> -DeWitt
>> On Sun, Aug 30, 2009 at 2:47 PM, Brad Fitzpatrick <bradf...@google.com> >> wrote:
>>> 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.
>>> On Sun, Aug 30, 2009 at 12:40 AM, Martin Atkins <m...@degeneration.co.uk> >>> wrote:
>>>> 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 wrote: > On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dclin...@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?
>> On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dclin...@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...)
> On Sun, Aug 30, 2009 at 6:31 PM, Martin Atkins <m...@degeneration.co.uk > >wrote:
>> Brad Fitzpatrick wrote:
>>> On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dclin...@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...)
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).
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?
On Sun, Aug 30, 2009 at 7:01 PM, Will Norris <w...@willnorris.com> wrote:
> On Aug 30, 2009, at 6:48 PM, Brad Fitzpatrick wrote:
> On Sun, Aug 30, 2009 at 6:31 PM, Martin Atkins <m...@degeneration.co.uk >> >wrote:
>>> Brad Fitzpatrick wrote:
>>> On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dclin...@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...)
> 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).
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
On Sun, Aug 30, 2009 at 5:30 PM, Blaine Cook <rom...@gmail.com> 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?
> b.
> 2009/8/31 Brad Fitzpatrick <b...@danga.com>: > > On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dclin...@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.
> >> -DeWitt
> >> On Sun, Aug 30, 2009 at 2:47 PM, Brad Fitzpatrick <bradf...@google.com> > >> wrote:
> >>> 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.
> >>> On Sun, Aug 30, 2009 at 12:40 AM, Martin Atkins < > m...@degeneration.co.uk> > >>> wrote:
> >>>> 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.)
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:
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.
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
From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of DeWitt Clinton Sent: Sunday, August 30, 2009 7:48 PM To: webfinger@googlegroups.com Subject: Re: google webfinger prototype updated...
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
On Sun, Aug 30, 2009 at 5:30 PM, Blaine Cook <rom...@gmail.com<mailto:rom...@gmail.com>> 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?
> On Sun, Aug 30, 2009 at 3:06 PM, DeWitt Clinton <dclin...@gmail.com<mailto:dclin...@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<http://tcp.gmail.com> > ;; ANSWER SECTION: > _xmpp-server._tcp.gmail.com<http://tcp.gmail.com>. 86400 IN SRV 5 0 5269 xmpp-server.l.google.com<http://xmpp-server.l.google.com>. > _xmpp-server._tcp.gmail.com<http://tcp.gmail.com>. 86400 IN SRV 20 0 5269 > xmpp-server1.l.google.com<http://xmpp-server1.l.google.com>. > _xmpp-server._tcp.gmail.com<http://tcp.gmail.com>. 86400 IN SRV 20 0 5269 > xmpp-server2.l.google.com<http://xmpp-server2.l.google.com>. > _xmpp-server._tcp.gmail.com<http://tcp.gmail.com>. 86400 IN SRV 20 0 5269 > xmpp-server3.l.google.com<http://xmpp-server3.l.google.com>. > _xmpp-server._tcp.gmail.com<http://tcp.gmail.com>. 86400 IN SRV 20 0 5269 > xmpp-server4.l.google.com<http://xmpp-server4.l.google.com>. > Where the 5269 is the port, and the hostname you'd connect to is in the last > column.
>> -DeWitt
>> On Sun, Aug 30, 2009 at 2:47 PM, Brad Fitzpatrick <bradf...@google.com<mailto:bradf...@google.com>> >> wrote:
>>> 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.
>>> On Sun, Aug 30, 2009 at 12:40 AM, Martin Atkins <m...@degeneration.co.uk<mailto:m...@degeneration.co.uk>> >>> wrote:
>>>> On Aug 17, 4:12 pm, Brad Fitzpatrick <bradf...@google.com<mailto: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<mailto: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<http://gmail.com> >>>> > or >>>> > googlemail.com<http://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<http://degeneration.co.uk> >>>> degeneration.co.uk<http://degeneration.co.uk> descriptive text "v=xrd1 url=http:// >>>> martin.atkins.me.uk/webfinger/degeneration.co.uk.xml<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.)
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.
>> 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.
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-http...@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.
> -----Original Message-----
> From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On
> Behalf Of Martin Atkins
> Sent: Monday, August 31, 2009 11:12 AM
> To: webfinger@googlegroups.com
> Subject: Re: google webfinger prototype updated...
> 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.
> [...] > 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?
> 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.
> 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.)
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...
> -----Original Message-----
> From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On
> Behalf Of Martin Atkins
> Sent: Monday, August 31, 2009 2:16 PM
> To: webfinger@googlegroups.com
> Subject: Re: google webfinger prototype updated...
> 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.)
-----Original Message-----
From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 31, 2009 2:26 PM
To: webfinger@googlegroups.com
Subject: RE: google webfinger prototype updated...
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: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On
> Behalf Of Martin Atkins
> Sent: Monday, August 31, 2009 2:16 PM
> To: webfinger@googlegroups.com
> Subject: Re: google webfinger prototype updated...
> 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.)
