1) Mimic the `finger` protocol for email-like identifiers --
discover basic user data (hcard), service profiles (xfn rel="me"),
perhaps contacts (xfn), etc. As Dewitt has demonstrated, this
certainly doesn't the complexity of XRD.
2) Use email-like identifiers to identify users in protocols that
rely on XRD for discovery. OpenID of course is the most obvious, but
there can and most certainly will be more... OAuth, Portable Contacts,
Activity Streams, etc. In order to make email-like identifiers work
in an XRD world, then we absolutely have to figure out how an XRD
descriptor is discovered for that identifier.
I guess the question really is, what is the desired scope of this
particular 'webfinger' project? If the goal is simply to accomplish
#1, that's fine, and Dewitt's proposal will likely work just fine.
But #2 is going to need to be done one way or the other. There has
been talk about using email addresses for OpenID for quite a long
time. The solution is likely going to be profiling LRDD To work with
email-like identifiers. If that work gets rolled into the webfinger
project, then great. If not, that's fine too.
For what it's worth, I'll note that I am not terribly interested in
#1. While it's cool and all, I can't help but see it as a single
service that does something only moderately useful. I'm interested in
seeing #2 happen, since that is building the infrastructure to use
email-like identifiers in countless identity related applications
going forward.
-will
On Aug 16, 2009, at 8:32 PM, Santosh Rajan wrote:
> Great piece of work!Folks will give you the usual arguments we have
>> 1. The client is given an email-like identifier
>> 2. The identifier is parsed into a local-part and a domain per
>> RFC 2822
>> 3. The domain is converted into a host URL at http://{domain}/
>> 4. The host URL is fetched, following redirects, to retrieve an
>> HTML
>> page
>> 5. The HTML page is parsed for the existence of a rel="finger" link
>> element
>> 6. The href target of the rel="finger" is parsed as a URL template,
>> substituting in the local-part or addr-spec as necessary
>> 7. The resultant URL is fetched, following redirects, and parsed
>> for
>> rel="me" anchors and links
>> 8. The links are returned as services associated with the
>> identifier
>>
>> In practice, this approach can be exceeding simple for a provider to
>> implement. In my own case, I simply added the following line of
>> HTML to my
>> homepage:
>>
>> <link rel="finger" href="http://finger.unto.net/search?q={addr-
>> spec}<http://finger.unto.net/search?q=%7Baddr-spec%7D>
Two observations. First, from the experience of getting OpenID support
at Yahoo! (and I believe Google as well), this is a no go since it
means adding stuff to insanely frequented pages when less than
0.00001% will actually care about those links. Second:
On Aug 16, 7:50 pm, DeWitt Clinton <dclin...@gmail.com> wrote:
> 6. The href target of the rel="finger" is parsed as a URL template,
> substituting in the local-part or addr-spec as necessaryThis violates HTML since href is defined as a URI.
as for hard-coding mappings from big sites, can't you use the existing
SGNodeMapper to go from mailto: to known profile URLs?
http://code.google.com/p/google-sgnodemapper/
>
>>
>> On Aug 16, 7:50 pm, DeWitt Clinton <dclin...@gmail.com> wrote:
>>
>> > 6. The href target of the rel="finger" is parsed as a URL template,
>> > substituting in the local-part or addr-spec as necessary
>>
>> This violates HTML since href is defined as a URI.
>
> Mea culpa here. I sincerely thought link href was under-specified in HTML5
> and invalid URIs could squeak through.
> But I will challenge the assertion that Will's use-case #1 of looking up
> services by email is uninteresting. Given the sudden flood of traffic to
> the test client by people plugging their gmail addresses and/or adding
> (invalid!) link rel headers to their page for identity lookup, I think this
> very simple XFN-based approach may indeed be of interest to some people.
> Either way, I will modify my client to support well-known and XRD once the
> spec is a little more polished. It's a fine starting place for a test
> client, and I don't regret at all trying to make a point about use-case #1.
> And I'll also continue to push for reuse of XFN (and maybe FOAF) because
> they already exist in the wild.
I think the two can coexist, certainly
This is easily fixed by adding back in SRV support (and illustrates
why you really can't do without a DNS lookup).
I don't think you can.
The correct conclusion here, IMO, is that the sandbox is too
restrictive. It should either provide DNS lookup services, or it
should support webfinger itself.
If you argue from the position that we should only ever do things that
fit inside current sandboxes, we are doomed to never move beyond
existing protocols. Which seems like a pretty sucky thing to be
arguing for.
Actually, I'll take that back. The easy answer is to stand up a look
up service that can be accessed over HTTP somewhere.
I still stand by the below, though.
This sounds very much in line with the thinking for web-linking[1]. I
feel a little funny using a URI-template in an HTML or Atom link.
That's the main advantage to XRD right now. It's interesting that HTML
forms don't have a rel attribute. I'd really love to know if you
think this is the right way to resolve a discovery document after
reviewing the web-linking draft.
If you're going to use a rel value in HTML, please define a profile.
If in XHTML, please give it a full URI.
> Finger templates can include either 'local-part' (e.g., 'dewitt') or
> 'addr-spec' (e.g. 'dew...@unto.net') as they prefer.
+1 to the terms 'local-part' and 'addr-spec'
> I could have implemented a new service at finger.unto.net to return
> a full document with all of the services associated with the
> account. But in my case, I already have a XFN based profile at
> Google, so all I needed to do was redirect to it. I did this with
> nothing more than a RedirectMatch in my httpd.conf.
>
> RedirectMatch ^/search\?addr-spec=dew...@unto.net$ http://www.google.com/profiles/dclinton
>
> *I mentioned that @gmail.com and @friendfeed.com addresses also work
> with the client. I did this by cheating. Both of those domains
> accept incoming email and expose XFN formatted profiles with a well-
> known mapping, so I hardcoded those by hand. I wouldn't recommend
> that clients do this by default, but I did want to show some other
> semi-working examples. Your site can work by following the
> instructions for link rel="finger" as above.
...
Practically, I'm most interested in the final page you're resolving
too. Since finger was designed to be a user-visible tool, not just an
underlying protocol, HTML seems to make a lot of sense. It might be
worth investigating mapping XRD into a microformat so there's some
equivalence between human optimized and tool optimized formats. XRD is
mostly just links and relations anyway.
The open question here seems to be: should webfinger resolve to a
discovery document which has a <link rel="profile"/> or should it
point to a profile with a <link rel="describedby"/>? Either should
solve both of the problems Will Norris mentioned.
1: http://tools.ietf.org/html/draft-nottingham-http-link-header
--
http://JosephHolsten.com
<link rel="finger" href="http://finger.unto.net/search?q={addr-spec}<http://finger.unto.net/search?q=%7Baddr-spec%7D>
This calls for representing this email-like identifier as a URI. URI is the generic identify architecture of the web and we should obey it, not try to create another construct next to it.
EHL
There is no need to replace tel: or http:… we should focus on the local-id/domain pair use case.
% svn checkout http://webfingerclient-dclinton.googlecode.com/svn/trunk/ webfingerclient% cd webfingerclient% python webfinger.py acct:dcli...@gmail.comsubject {value: "acct://dcli...@gmail.com" } [...snipped...]
% python2.5>>> import urllib >>> import xrd >>> content = urllib.urlopen('http://gmail.com/.well-known/host-meta').read() >>> parser = xrd.Parser() >>> description = parser.parse(content) >>> str(description) 'subject {\n value: "http://gmail.com/"\n}\nlinks {\n relations {\n value: "http://webfinger.info/rel/service"\n }\n uri_templates {\n value: "http://www.google.com/s2/webfinger/?q={%id}"\n }\n}\nlinks {\n relations {\n value: "describedby"\n }\n uri_templates {\n value: "http://www.google.com/s2/webfinger/?q={%id}"\n }\n}\n'
And I see I don't need the "acct:" prefix and you do the right thing
and assume email-like is acct:. Perfect!
Simple, readable code too! And nice seeing protos used. :-)