Few Questions

[Steven Livingstone-Perez]

Hi - as an avid user of Finger in my Uni days this is an interesting project.

 

I do have a few (possibly ignorant) questions though based on what i read at the start. I read the following:

 

"People have been trying to use URLs as identifiers for people (as OpenID does), as it has great readability/discoverability properties, but this effort has largely failed because of UI/UX design failings, user confusion about URLs"

 

Whilst i like the idea as an *identifier* i don't believe the above is actually a true statement on how things work out there. Whilst i do agree that the confusion with OpenID requiring a user to know a full URL to login is generally true (more about gradually improving UX if anything), i'm not convinced that URL's are any more confusing than email and may in fact be easier. I do think OpenID needs email to make the UX make sense but OpenID seems to me to be the logical choice as an identifier (in nothing more than not to add more concepts).

 

For example, people now say "You can get my on Facebook" or "I am weblivz on Twitter" and so on a lot more than "My email is firstname...@domain.com" and so on - especially on the social web.. and especially in the non-technical majority. Discovery - certainly to this point - of a person associated with a URL has been much easier. If i don't know your name it's pretty easy to search a directory [or even some search upstart called Google ] to find the person i am interested in without them telling me much about them at all and keeping the relationship on their terms (kinda like having a 3rd party managed virtual business address).

 

An additional advantage that it is effectively read-only... once you get my email I no longer control the relationship.

 

In other words that idea that the email rather than URL should be used as the finger identifier (if that is the correct terminology) seems counter-intuitive to where the popular uses of URLs in the wild are.

 

In fact there is perhaps a strong argument that the identifier needs to be a URL - that might even be virtual with no data store behind it... simply as an identifier to which metadata can be attached and put out there as a readonly endpoint with the associated metadata attached to that (which in turn via the various methods of authentication can follow the desired privacy levels of the users - or the law).

 

I know i'm chiming in late on this and have quite a bit more to find out about it all but initial thoughts anyway.

 

regards,

steven

http://livz.org

[Will Norris]

It's been said a few times already, but it's worth repeating.
WebFinger is not using email addresses. It is using email-like
identifiers. This also means that they are XMPP-like identifiers, as
well as Wave-like identifiers, as well is eduPersonPrincipalName-like
identifiers (for those from the higher education crowd). It is an
identifer that is made of "username@host". So we're not necessarily
talking about giving away "control [of] the relationship".

It's also worth thinking about webfinger as two different things.
There is webfinger the protocol that will define how to take the
aforementioned email-like identifier and get some metadata about it.
As you sort of mentioned, we can already do this with URLs (as well as
with XRIs). But we don't yet have a standard protocol for discovering
services for a user that is identified solely by an email-like
identifier. That's one of the goals of webfinger -- to define how
that discovery occurs.

The other part of webfinger is the program. Perhaps a command-line
utility like finger, perhaps a web service... most likely both. This
utility will allow you to specify some user identifier, and it will
return some information about the user, just like finger did. We
don't yet know what data it will display... we've got time to figure
that out. But the important thing to note here is that there is
nothing about this utility that necessitates the above email-like
identifier. I fully expect to be able to pass a URL, XRI, email-like
identifier, hell maybe even a phone number to the webfinger utility,
and it will do the same thing.

While your point about URL identifiers is well-taken, it's important
to understand that this isn't about "URLs vs Email Addresses" as the
predominant user identifier going forward. This is about leveling the
playing field so that any kind of user identifier can be used to
discover information about the user.

-will

On Aug 16, 2009, at 11:18 AM, Steven Livingstone-Perez wrote:

> Hi - as an avid user of Finger in my Uni days this is an interesting
> project.
>
> I do have a few (possibly ignorant) questions though based on what i
> read at the start. I read the following:
>
> "People have been trying to use URLs as identifiers for people (as
> OpenID does), as it has great readability/discoverability
> properties, but this effort has largely failed because of UI/UX
> design failings, user confusion about URLs"
>
> Whilst i like the idea as an *identifier* i don't believe the above
> is actually a true statement on how things work out there. Whilst i
> do agree that the confusion with OpenID requiring a user to know a
> full URL to login is generally true (more about gradually improving
> UX if anything), i'm not convinced that URL's are any more confusing
> than email and may in fact be easier. I do think OpenID needs email
> to make the UX make sense but OpenID seems to me to be the logical
> choice as an identifier (in nothing more than not to add more
> concepts).
>
> For example, people now say "You can get my on Facebook" or "I am
> weblivz on Twitter" and so on a lot more than "My email is firstname...@domain.com
> " and so on - especially on the social web.. and especially in the
> non-technical majority. Discovery - certainly to this point - of a
> person associated with a URL has been much easier. If i don't know
> your name it's pretty easy to search a directory [or even some

> search upstart called Google <Emoticon3.gif>] to find the person i

[Steven Livingstone-Perez]

Thanks Will.

I'd make a slight argument for the brief on Google Code to update this as on
initial reading it seems to be about email v URL (possibly why it's being
asked over again).

The discovery part should be really interesting, especially combined with
oAuth or something to control access.... i guess with privacy enhancements
to oAuth or some new protocol.

steven
http://livz.org

--------------------------------------------------
From: "Will Norris" <wi...@willnorris.com>
Sent: Sunday, August 16, 2009 7:33 PM
To: <webf...@googlegroups.com>
Subject: Re: Few Questions