Let's do this.

[Brad Fitzpatrick]

I've been talking about the importance of WebFinger to people here at Google and I've been hearing a unanimous "yes, of course, let's do it" from everybody.

And now that Mark Nottingham & Eran Hammer-Lahav wrote up draft-nottingham-site-meta-02 about /.well-known/, I figure it's time to get going....

To that end,

# For discovery:

http://gmail.com/.well-known/host-meta

https://gmail.com/.well-known/host-meta

http://googlemail.com/.well-known/host-meta

https://googlemail.com/.well-known/host-meta

# For serving results:

http://www.google.com/s2/webfinger/

https://www.google.com/s2/webfinger/

Those all point to a public but non-production job that we can push updates to on a moment's notice.  (I figure those are all the endpoints we'll need, but we can add more if needed....)

We've also created an experiment and opt-ed in a ~dozen Googler guinea pigs whose @gmail.com address will be webfinger-able.  All other @gmail.com address won't be, until we figure out policies / messages / UIs / opt-{ins,outs}, etc.

In other words, we've eliminated both technical & political hurdles.  We can now work on this spec, implement, push, try, rinse, repeat.... until we're all reasonable happy.

So yeah, let's do this.  :-)

- Brad

[Will Norris]

Is the plan to use XRD for gmail's host-meta, or the older plain-text
version that is being recommended here[0]? LRDD will be defining XRD
as the document type for host-meta, but is just waiting on a committe
draft to be published (which should be in the next week or two, I'm
hoping). The schema for XRD 1.0 is certainly stable enough to use,
and the latest draft can be found here[1]. There have been a few
minor changes since that draft, but mostly editorial changes and a few
typos[2].

The current java XRD implementation I'm working on for Internet2 is
available here[3], though it's not complete. Implements XRD document
marshalling and unmarshalling, should handle signing, though I haven't
dug into that yet. Big outstanding piece is document discovery
(LRDD), and a few utility classes.


[0]: http://groups.google.com/group/google-federated-login-api/web/openid-discovery-for-hosted-domains
[1]: http://tools.oasis-open.org/version-control/svn/xri/xrd/1.0/drafts/wd04
[2]: http://tools.oasis-open.org/version-control/svn/xri/xrd/1.0/trunk/
[3]: http://github.com/willnorris/java-openxrd

-will

> @gmail.comaddress won't be, until we figure out policies / messages /

[David Recordon]

Sweet, this is great news! I'm really excited to see this work come
together so that we can move to supporting it in OpenID.

--David

On Aug 14, 12:23 pm, Brad Fitzpatrick <bradf...@google.com> wrote:
> I've been talking about the importance of WebFinger to people here at Google
> and I've been hearing a unanimous "yes, of course, let's do it" from
> everybody.
>
> And now that Mark Nottingham & Eran Hammer-Lahav wrote
> up draft-nottingham-site-meta-02 about /.well-known/, I figure it's time to
> get going....
>
> To that end,
>

> # For discovery:http://gmail.com/.well-known/host-metahttps://gmail.com/.well-known/host-metahttp://googlemail.com/.well-known/host-metahttps://googlemail.com/.well-known/host-meta
>
> # For serving results:http://www.google.com/s2/webfinger/https://www.google.com/s2/webfinger/

>
> Those all point to a public but non-production job that we can push updates
> to on a moment's notice.  (I figure those are all the endpoints we'll need,
> but we can add more if needed....)
>
> We've also created an experiment and opt-ed in a ~dozen Googler guinea pigs
> whose @gmail.com address will be webfinger-able.  All other

> @gmail.comaddress won't be, until we figure out policies / messages /

[Brad Fitzpatrick]

On Fri, Aug 14, 2009 at 12:39 PM, Will Norris <wi...@willnorris.com> wrote:

Is the plan to use XRD for gmail's host-meta, or the older plain-text
version that is being recommended here[0]?

I personally don't care.  Last I heard more people seemed happy with XRD.  We'll support both if we have to (switch on HTTP Accept header?).

To be clear, I don't think anybody here cares much about XRD vs XRDS, nor about XML vs TXT vs JSON vs RDF vs whatever for the payload.

Our interest is in making email(-looking) identifiers readable entities, not squabbling over syntax.  So when the community all agrees on something, I think we'll just go along with it.

One thing I have heard Dirk & others say is that they don't like XML-DSIG and would rather just sign the HTTP response payload in the HTTP response headers.  But I'm staying out of that, too, just because I don't have much of an opinion.

[3]: http://github.com/willnorris/java-openxrd

Cool!  That might come in handy, at least initially for unit tests against what our server emits.

[Blaine Cook]

Awesome, thanks for pushing this. Any chance we could enable WebFinger
on non-Googlers gmail accounts?

b.

On Aug 14, 8:23 pm, Brad Fitzpatrick <bradf...@google.com> wrote:
> I've been talking about the importance of WebFinger to people here at Google
> and I've been hearing a unanimous "yes, of course, let's do it" from
> everybody.
>
> And now that Mark Nottingham & Eran Hammer-Lahav wrote
> up draft-nottingham-site-meta-02 about /.well-known/, I figure it's time to
> get going....
>
> To that end,
>

> # For discovery:http://gmail.com/.well-known/host-metahttps://gmail.com/.well-known/host-metahttp://googlemail.com/.well-known/host-metahttps://googlemail.com/.well-known/host-meta
>
> # For serving results:http://www.google.com/s2/webfinger/https://www.google.com/s2/webfinger/

>
> Those all point to a public but non-production job that we can push updates
> to on a moment's notice.  (I figure those are all the endpoints we'll need,
> but we can add more if needed....)
>
> We've also created an experiment and opt-ed in a ~dozen Googler guinea pigs
> whose @gmail.com address will be webfinger-able.  All other

> @gmail.comaddress won't be, until we figure out policies / messages /

[Brad Fitzpatrick]

On Fri, Aug 14, 2009 at 12:58 PM, Blaine Cook <rom...@gmail.com> wrote:

Awesome, thanks for pushing this. Any chance we could enable WebFinger
on non-Googlers gmail accounts?

Sure, I think.... why not?  :-)  If it doesn't get out of control sign-up wise, at least.  Probably just people participating in the protocol's design.

I'll need some sort of opt-in confirmation, though.  Anybody want to whip up a hello-world app engine app that requires login & has you agree to some text and logs the authenticated email?  Or maybe that's too formal.

Let's figure this out later when we start to have something working.

[J. Chris Anderson]

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

> On Fri, Aug 14, 2009 at 12:39 PM, Will Norris <w...@willnorris.com> wrote:
>
> > Is the plan to use XRD for gmail's host-meta, or the older plain-text
> > version that is being recommended here[0]?
>
> I personally don't care.  Last I heard more people seemed happy with XRD.
>  We'll support both if we have to (switch on HTTP Accept header?).

+1 for switching on Accept header - I'd love to see a simple JSON
representation of whatever data structure ends up getting used.

> > > So yeah, let's do this.  :-)
>
> > > - Brad

Thanks for pushing the bobsled.

Chris

[Eran Hammer-Lahav]

Default (no Accept) will be XRD. That's how host-meta is going to be defined. Anything you serve with Accept is beyond what I set to do. The tricky bit will be with trust since XRD uses an XML attribute to indicate the scope of the file (more on that later) and that means you won't be able to just to a dumb conversion of XRD XML to JSON.

EHL

[Eran Hammer-Lahav]

I’ll get the new LRDD spec out early next week and with the XRD WD4, you will have pretty much everything except for the webfinger <Type>.

 

EHL

[Mark]

Nice concept, I could see this integrating/relating with hCard
microformat. Or would this shadow it...

On Aug 14, 1:23 pm, Brad Fitzpatrick <bradf...@google.com> wrote:
> I've been talking about the importance of WebFinger to people here at Google
> and I've been hearing a unanimous "yes, of course, let's do it" from
> everybody.
>
> And now that Mark Nottingham & Eran Hammer-Lahav wrote
> up draft-nottingham-site-meta-02 about /.well-known/, I figure it's time to
> get going....
>
> To that end,
>

> # For discovery:http://gmail.com/.well-known/host-metahttps://gmail.com/.well-known/host-metahttp://googlemail.com/.well-known/host-metahttps://googlemail.com/.well-known/host-meta
>
> # For serving results:http://www.google.com/s2/webfinger/https://www.google.com/s2/webfinger/

>
> Those all point to a public but non-production job that we can push updates
> to on a moment's notice.  (I figure those are all the endpoints we'll need,
> but we can add more if needed....)
>
> We've also created an experiment and opt-ed in a ~dozen Googler guinea pigs
> whose @gmail.com address will be webfinger-able.  All other

> @gmail.comaddress won't be, until we figure out policies / messages /

[Brad Fitzpatrick]

On Fri, Aug 14, 2009 at 2:06 PM, Mark <ma...@markmathson.com> wrote:

Nice concept, I could see this integrating/relating with hCard
microformat. Or would this shadow it...

Complements it.

email -> webfinger discovery -> webfinger -> some HTML url (profile, blog, etc) -> hcard -> info

 

[John Panzer]

It'll be great to see if there really are any caching proxies which mess up Vary: Accept.

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

[Santosh Rajan]

Great stuff, been waiting for this for months.

+1 for accept header, JSON might be a great idea.

--
http://santrajan.blogspot.com
http://twitter.com/santoshrajan
http://www.facebook.com/santosh.rajan

[Nenad V. Nikolic]

Kudos for a great initiative! :-)

It would be great to have the name/finger protocol back, this time
making user info available as "any" content/payload type over HTTP(S).
Various web services and mashups might use WebFinger in creative ways.

Assuming that the security model will basically rely on SSL (and CAs),
I'm curious about the access control part and how additional/related
user info (e.g. phone number, home address) will be made available to
selected recipients (humans and machines).
Have you had this in mind? If yes, how it would work?
How would WebFinger implementor specify and, subsequently, how would
user (email id owner) define control access to the information
returned and how will this be specified?

From what I can tell, various XSD Link elements would point to
additional endpoints that might require additional authentication,
delegating the access control to the servers that are being linked to.
I would assume each endpoint could be somehow associated to a groups
of users. Something that comes to mind are groups in Google Contacts,
each of which an be used for controlling access to private information
in one's Google Profile as well. Then the question is how such feature
could be made generic without tying WebFinger to Google. I hope Eran
could also chime in on this one.

Cheers!
Nenad

On Aug 14, 9:23 pm, Brad Fitzpatrick <bradf...@google.com> wrote:
> I've been talking about the importance of WebFinger to people here at Google
> and I've been hearing a unanimous "yes, of course, let's do it" from
> everybody.
>
> And now that Mark Nottingham & Eran Hammer-Lahav wrote
> up draft-nottingham-site-meta-02 about /.well-known/, I figure it's time to
> get going....
>
> To that end,
>

> # For discovery:http://gmail.com/.well-known/host-metahttps://gmail.com/.well-known/host-metahttp://googlemail.com/.well-known/host-metahttps://googlemail.com/.well-known/host-meta
>
> # For serving results:http://www.google.com/s2/webfinger/https://www.google.com/s2/webfinger/

>
> Those all point to a public but non-production job that we can push updates
> to on a moment's notice.  (I figure those are all the endpoints we'll need,
> but we can add more if needed....)
>
> We've also created an experiment and opt-ed in a ~dozen Googler guinea pigs
> whose @gmail.com address will be webfinger-able.  All other

> @gmail.comaddress won't be, until we figure out policies / messages /

[Eran Hammer-Lahav]

There are at least two separate issues here:

1. How can a client verify that an XRD document received (either for host-meta or an individual identifier) is valid and was authored by the same entity who controls the identifier?

2. How should users control who has access to their data contained within their XRD?

For now #2 will be mostly ignored and anything in there will be assumed public. Users will simply opt-in to either share information or not. For #1, this will be a combination of signing XRD documents and using a few XRD trust-specific elements, but again, this will be driven by actual use cases and for now the primary one is using this flow for (email identifiers for) OpenID.

EHL

> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Nenad V. Nikolic
> Sent: Saturday, August 15, 2009 5:57 AM
> To: WebFinger
> Subject: Re: Let's do this.
>
>

[Blaine Cook]

I'm actually really only interested in #2; for syndication of public
data, we have RSS/Atom and that works fine except where it doesn't.
Where private data is required, we have Facebook and Twitter and
Flickr and so on. Private and semi-private data is massively
important.

The problem as it stands is that there's no way with Atom or RSS to
say "Hi, I'm Bob and I'd like to subscribe to your private feed." For
me, webfinger is about being able to say "Hi, I'm Bob(@example.com)"
and have the person to whom you're talking be able to verify that and
later give you permission to some of your private data.

The exact mechanisms that all this would work are a bit unclear, but
maybe something like OAuth or webfinger-aware PubSubHubbub. In terms
of interface, a resource that the user exposes via their XRD should
have some way for people on the internet to request permission to
subscribe or view data, which is basically the same as what happens
when you click "Follow" on a private person on Twitter, or request to
add someone as a friend on Facebook. The service asks you if you want
to approve the request, and then more protocol stuff happens so that
the requestor can view your stuff.

Hopefully that clarifies things a bit?

b.

2009/8/15 Eran Hammer-Lahav <er...@hueniverse.com>:

[Christian M. Jensen]

What are the current thought surrounding crawlers?

For myself, I don't mind getting just about anything discovered about me
- my friends, what I am doing - but I would hate for someone to find out
that I have a Ferrari parked in my garage and I am on a month long
vacation. I would also be slightly more annoyed if I came home and it
was gone.

A crawler knowing my email address would be able to find out where I
live and maybe know my income from other data - but then make the
connection with what I am currently doing, get the keywords and alert a
bad guy.

I know this is far-fetched but you can change out pieces of this puzzle
(stalkers, con-men, other bad guys) and it still works.

The basic question is: how do I control the outgoing information without
my response being necessary? For example, I just met a few business
contacts at a conference - they want to know more about me - I don't
mind them knowing, so they should be able to access my info.

The first thought that jumps to mind is "If I have ever emailed address
X, then address X can see my stuff" - maybe even they email my address
with the word "webfinger" as the subject. I know it is not a URL but I
am just throwing out seed ideas here.

[Brad Fitzpatrick]

Then you'd only expose publicly a service endpoint that lets people authenticate (with, say OAuth/OpenID) to find out where your Ferrari is parked.  And only tell people you trust that you're gone on vacation for a month with your car parked outside.

But today you can't even do that.  You can't even ask to ask for information!  (much less get it some way....)

Nobody's going to make all your info public for you.  This is just a technology to let you expose what you want, in a standardized way.

[Eran Hammer-Lahav]

All of which comes after you get the user's XRD. XRD is just a bunch of links with little metadata. Some of those links will have access control but getting the XRD (for now) is public.

[Malcolm]

I notice you did not consider the second biggest personal IDs in your
list of possibles - mobile numbers. Why not?
These can resolve to URLs so long as you know the ID of the
responsible carrier. And all countries (that I know of) publish this
information, as part of number portability requirements, so it should
be possible to resolve +121212345678 to 21212...@ATT.com (say).
The carriers went down the path of a similar initiative to Webfinger -
ENUM - and that ended in disaster due to commercial conflicts. How do
you propose to resolve the same issues? Carriers implemented ENUM but
in the published user profiles they limited the publishing of
competitive information (such as alternative phone numbers, websites
or email addresses). How can you trust that the information from a
third party proxy is the truth, the whole truth and nothing but the
truth?
Users will also have the problem that if they change ID provider they
have to republish their information (possibly not a substantial issue
in an OpenSocial world).
You end up in one of four worlds:
* User managed proxies - webfinger world with issues of trust and user
managed identities across proxies
* Independent profile publishers - user proxies like .tel, .mp, etc, -
trust and user managed identities remains an issue
* Monopoly publishers - if all your stuff is in Google there is no
conflict or suspicion of lack of trust (except where trust might
conflict with Google - Microsoft users anyone?)
* User Controlled Publishing - Let the user directly publish
information to the requestor - ie Glynx (eg OpenID login without
private credentials)
Lack of trust and commercial conflict issues are "baked in" to the web
addressing architecture due to its proxy nature. How do you solve
this?

On Aug 15, 5:23 am, Brad Fitzpatrick <bradf...@google.com> wrote:
> I've been talking about the importance of WebFinger to people here at Google
> and I've been hearing a unanimous "yes, of course, let's do it" from
> everybody.
>
> And now that Mark Nottingham & Eran Hammer-Lahav wrote
> up draft-nottingham-site-meta-02 about /.well-known/, I figure it's time to
> get going....
>
> To that end,
>

> # For discovery:http://gmail.com/.well-known/host-metahttps://gmail.com/.well-known/host-metahttp://googlemail.com/.well-known/host-metahttps://googlemail.com/.well-known/host-meta
>
> # For serving results:http://www.google.com/s2/webfinger/https://www.google.com/s2/webfinger/

>
> Those all point to a public but non-production job that we can push updates
> to on a moment's notice.  (I figure those are all the endpoints we'll need,
> but we can add more if needed....)
>
> We've also created an experiment and opt-ed in a ~dozen Googler guinea pigs
> whose @gmail.com address will be webfinger-able.  All other

> @gmail.comaddress won't be, until we figure out policies / messages /