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

yeah, i saw that; i think for now we should not be distracted by what
is being discussed inside the webfinger community (even though some of
us are members of both), and just use what webfinger community
recommends/exposes, which right now is
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-00

if in the future webfinger announces a change, then we'll adapt - i'm
pretty sure since webfinger is super simplistic, any change they make
will also be super simple to implement, so that's why i don't worry
about it.

if anyone is worried about the work they may have to do in the future
because of changes to webfinger, then i would recommend using an open
source implementation (like StatusNet) and keep up with software
updates. i personally commit to sending you a pull request to make the
change in your code, if that would at any point be necessary.

On Sun, Jul 8, 2012 at 9:27 PM, Markus Sabadello
<markus.sabadello@gmail.com> wrote:
> Hmm this came out today:
> https://datatracker.ietf.org/doc/draft-snell-web-index/?include_text=1
>
> "The .well-known/index Mechanism"
>
> It says SWD is "far better" than WebFinger, and it proposes a new method.
>
> Apparently you hash the identifier, e.g. if your identifier is
> acct:joe.smith@online-service-provider.example.org
>
> Then you do a GET on
> /.well-known/index/53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/calendar
>
> And the discovery information is sent to you in HTTP headers of the
> response.
>
> Markus
>
>
> On Sat, Jul 7, 2012 at 4:22 PM, Michiel de Jong <michiel@unhosted.org>
> wrote:
>>
>> 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 Monday, 9 July 2012 06:13:16 UTC