Re: the possible impact of future changes in webfinger (was Re: Anonymity and multiple identities)

Daniel Harris, thanks for your interest! As soon as these email
threads lead to some conclusions we'll consolidate them on the wiki
(for now it's too much in flux i would say).

Melvin, as I already said, I agree with Dan that we should build stuff
even if there is a risk that not 100% of what we put in there will
crystalize, or will crystalize in the forms we use today. You seem to
be saying that webfinger is useful but there are better alternatives.
So let's look at what those candidate alternatives are, and evaluate
each one.

On Sat, Jul 7, 2012 at 2:35 PM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> I think pretending that your solution is the ONLY solution is inaccurate.
> There's lots of great technology on the web, and on
> the social web, and may the best systems win.

i'm not saying it's the only building block, i'm just saying it plays
a unique part in the puzzle. and actually you're right that this is a
slight simplification of the current state of affairs, because I
actually know of 4 alternatives (see below), but they are not the ones
you mention.

> Webfinger should be a standard by now

[...]

> In the meantime linked data, and for example facebook open graph, have
> become standards and have been adopted by 10's of millions of sites, as a
> way of discovering information.

that suggests that you see linked data and facebook open graph as
alternatives to webfinger, which IMHO they are not. First of all,
webfinger is (or wants to be) part of linked data. it's a specific
type of linked data where the data that is being linked is not
election results, or marmelade ingredients, but user profiles on the
social web.

Facebook open graph is another thing (i'm hesitant to call a
vendor-specific API a standard) that is based on and part of linked
data. It's a specific type of linked data where the data that is being
linked is not user profiles on the social web, but user profiles (and
group pages etcetera) on Facebook.

So i think we are using linked data by definition (it's the web of
data), and Facebook's api is one substituent part, and webfinger is
another substituent part. So i think your view and my view are fully
compatible. linked data, facebook and webfinger all have their place
in the edifice.

Now as to alternatives to webfinger, which is the main question here,
let's see what choices we have. So to define what constitutes an
alternative to webfinger, let's define the following requirements:

1 - it must be a scheme that given some sort of human-memorable ASCII
string, always produces the same structured data object.
2 - the human-memorable ASCII string should be understood by users to
have a one-to-one mapping to online identities
3 - there should be no centralized control on minting these strings,
other than DNS which we are sort of bound to already any way, by
virtue of being on the web.
4 - the person who operates a specific online identity, or (in case
DNS is used) the sysadmin of the domain this online identity belongs
to should have control over the contents of said structured data
object.

So facebook open graph does 1, 2 and 4, but not 3, so it doesn't
qualify as an alternative to webfinger.
You could use URLs of foaf documents directly or in client-side certs,
which would satisfy constraints 2,3 and 4, but not constraint 1.

The three scheme i know of which you could use, are xmpp disco,
mozilla persona profile, and simple web discovery. Of these, simple
web discovery is being merged into webfinger, and these are no longer
considered 2 competing protocols, rather the question is which
features of each will make it into the next format. but we can follow
the decision of IETF on that, it would not be constructive to go mount
a parallel process for that right now.

Xmpp disco is a valid alternative to webfinger i think, but the
downside is that it cannot be accessed from the browser, which is why
i would think it's better to at least also always offer webfinger.

Mozilla persona profile data is meant to travel from IdP to RP only
via the user's in-situ consent, which means it cannot be used to host
a public profile - it's more of a way in which the browser remembers
form data while you are interacting with the web, than a part of your
online presence on the web.

And then there is the option of doing nothing, and not defining a
unified preferred way to refer to a user. That, i think, can only lead
to silo's, which is what we're seeing now.

So as far as i can see the only two realistic options are webfinger
and xmpp disco. Of these, i would prefer webfinger.

Does that make sense? let me know if you see any other options that
would match the 4 requirements i mentioned, or if you think those 4
requirements are flawed.


Cheers!
Michiel

Received on Saturday, 7 July 2012 14:23:19 UTC