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....
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 / 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.
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.
> 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....
> 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 /
> 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.
> 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....
> 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 /
> 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.
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?).
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.
> On Aug 14, 2009, at 12:23 PM, Brad Fitzpatrick 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....
> > 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 /
> > 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.
> 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....
> 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 /
> 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.
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.
> 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....
> > 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 /
> > 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.
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.
> -----Original Message-----
> From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On
> Behalf Of J. Chris Anderson
> Sent: Friday, August 14, 2009 1:04 PM
> To: WebFinger
> Subject: Re: Let's do this.
> 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.
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
From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Brad Fitzpatrick
Sent: Friday, August 14, 2009 12:23 PM
To: webfinger@googlegroups.com
Subject: Let's do this.
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....
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<http://gmail.com> address will be webfinger-able. All other @gmail.com<http://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.
> 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....
> 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 /
> 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.
It'll be great to see if there really are any caching proxies which mess up
Vary: Accept.
--
John Panzer / Blogger
jpan...@google.com / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer
On Fri, Aug 14, 2009 at 1:46 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> 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
> > -----Original Message-----
> > From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On
> > Behalf Of J. Chris Anderson
> > Sent: Friday, August 14, 2009 1:04 PM
> > To: WebFinger
> > Subject: Re: Let's do this.
> > 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.
On Sat, Aug 15, 2009 at 3:07 AM, John Panzer <jpan...@google.com> wrote:
> It'll be great to see if there really are any caching proxies which mess up
> Vary: Accept.
> --
> John Panzer / Blogger
> jpan...@google.com / abstractioneer.org <http://www.abstractioneer.org/> /
> @jpanzer
> On Fri, Aug 14, 2009 at 1:46 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
>> 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
>> > -----Original Message-----
>> > From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On
>> > Behalf Of J. Chris Anderson
>> > Sent: Friday, August 14, 2009 1:04 PM
>> > To: WebFinger
>> > Subject: Re: Let's do this.
>> > 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.
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....
> 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 /
> 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.
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.
> -----Original Message-----
> From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On
> Behalf Of Nenad V. Nikolic
> Sent: Saturday, August 15, 2009 5:57 AM
> To: WebFinger
> Subject: Re: Let's do this.
> 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....
> > 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 /
> > 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.
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 <e...@hueniverse.com>:
> 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: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On
>> Behalf Of Nenad V. Nikolic
>> Sent: Saturday, August 15, 2009 5:57 AM
>> To: WebFinger
>> Subject: Re: Let's do this.
>> 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....
>> > 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 /
>> > 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.
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.
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.
On Sat, Aug 15, 2009 at 3:37 PM, 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.
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.
> -----Original Message-----
> From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On
> Behalf Of Blaine Cook
> Sent: Saturday, August 15, 2009 3:35 PM
> To: webfinger@googlegroups.com
> Subject: Re: Let's do this.
> 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 <e...@hueniverse.com>:
> > 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: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com]
> On
> >> Behalf Of Nenad V. Nikolic
> >> Sent: Saturday, August 15, 2009 5:57 AM
> >> To: WebFinger
> >> Subject: Re: Let's do this.
> >> 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....
> >> > 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 /
> >> > 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.
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 21212345...@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....
> 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 /
> 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.
|
