Consider using emails instead of URIs for identity

[steveklabnik]

One of the reasons that OpenID failed so hard was that they used URIs for identity; users are much, much more familiar with an email as an identifier.

WebFinger is one sample standard that may help here.

[max-mapper]

+1 on emails, -1 on webfinger specifically. .host-meta is weird, XML sucks (jrdd never went anywhere) and it would be way easier to take the same principles and do them in a JSON+RESTier way

[steveklabnik]

I agree that WebFinger is not ideal and rubs me the wrong way, but it already has wide support, which I consider to be a bigger deal, personally. Regardless, emails are the point.

[wilkie]

I agree that .well-known/.host-meta is strange and out of place. I don't think it is enough to condemn webfinger.

Before we go reimplement a JSON version of LRDD, and invoke the concept of REST here... maybe we could get the input from @blaine since although webfinger is not a complicated specification, reimplementing something that is so important for online identity should be handled by many knowledgeable people. It is nice to have this problem solved in a way that has seen many eyes and is widely adopted. We may be able to add a JSON content representation to the webfinger spec if we claim, as we do, that it is important to have. (We will still, naturally, have to provide the XML one as a provider)

[max-mapper]

http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/

[wilkie]

Yeah. There are JSON representations of these things. Same with activity streams, etc. You just have to wonder why we don't just use them. I guess, what we need to do... is... use them! :)

[max-mapper]

speaking generally most things that take XML protocols and convert them to JSON miss the point of JSON

[wilkie]

The protocol is how you get the information, the XML is the representation of the resource. I guess I miss your point, too, but as long as I can pull the same information out of the JSON, no matter how that is done, I can have both the protocol and the smaller, friendlier content type. :)

[max-mapper]

what i'm really getting at is that I think most of the federated protocols are overengineered and the harder it is to implement something the less implementations you get. if someone comes along with the ability to ship a compelling product and also ships some simple protocols for interacting with their product in a decentralized way then I think that would be awesome. my last piece of advice would be to prioritize making it fun for third party devs to implement whatever spec you end up shipping. now I'm really off topic for this thread :)

[wilkie]

That opinion seems legit. :)

[tmcnab]

Why not adopt BrowserID/Persona?

[blaine]

Please use the JSON version – the XML stuff was really to try to get buy-in from a bunch of people who said they'd support the standard if it was XML – it's early days for all of this stuff, and as long as the cost to adapt is low, "may the best standard win". +1 to Max's "make it fun" comment.

As far as this thread is concerned, the only thing I care about is that people don't have to register a domain in order to use a "free" social network. I care less about the "indie, I run my own server" story than I do about the "I can choose which organisation provides my services" story.

My assumption has always been (for over five years now!) that in order to give the full federated story, we need to have a way of explaining stable federated identifiers to people. We need to be able to give regular people a way to say their name(s). That name is email. It's the most successful stable, portable, and globally-unique identifier we've ever had. "Jesus of Nazareth" is practically an email address as far as formatting goes, so it's not even new from a cognitive level.

So yeah, whatever decisions you make, please use email addresses, and please offer some form of discovery mechanism. The discovery mechanism is important so that we mere mortals don't need to remember all the URLs of all the social services we use (this is one of two things that OpenID failed at up so badly (and continues to fail at)).

... on a more general note, while I'm here, I'd go further than Max in saying "build something fun to build": I'd say "build something [that's not a protocol]."

The protocol can be extracted later as we have more successful examples of these services actually working in the wild.

FWIW, I've blogged about simple authenticated federation protocols before: http://blog.romeda.org/2011/03/private-webhooks-private-feeds.html and it's not just how simple or fun protocols are that makes them successful. In case you don't read the post, I explain a full secure protocol flow [that works] using curl and little barnyard animals, in about a dozen slides, including the human interactions (which protocol designs often forget). The point is that the protocol isn't the hard bit.

The hard bit is building a service that people care to use, that has carefully considered and successful interaction design, and that can serve as an example for others moving forward.

PS: It makes me so, so happy to see you guys working on tent.io, and that you're doing a great job. :-D

[beberlei]

I agree that emails are way better than urls. If urls are technically necessary (which it seems they are), why not have an automatic conversion of emails into tent urls based on conventions?

[blaine]

@beberlei because there's no way to convert my email address, "romeda@gmail.com", into a tent.io URL. Having many email addresses (i.e., one per user-service) is far from ideal (though it might be a viable stop-gap solution).

[moritan]

email convertion can only be used by a centralized server.
a tent service provider could offer this service for his customer (only on his server) but a distribute service like tent.io would need some kind of global registrar server to do the same.
If you do so, it will not be distribute anymore but centralized.

For me having something like : "tent.io/moritan" or "moritan@tent.io" is the same and one is an url, the other an email.
By the way a server may provide a search service for user by email. But search will not be perform globally but locally on this server.
I don't have seen distribute seach/auto-discover protocole over the network for server in spec but it could be a funny feathure.

Perform search on a subject throught all the servers would be great !

[wrr]

For an example of how emails (verified with Persona, which is a distributed system) can be used for application independent authorization take a look here: https://github.com/wrr/wwwhisper

Have you considered extracting authorization layer from the protocol, so authorization is not social networking specific? If you used a generic layer that allows you to specify that alice@foo.org can POST to a given URL, then you could use this layer for distributed social networking service where POST can mean 'post an update on the wall'. But you could also use the same authorization layer for any other web application, where POST can mean something completely different. If you build authorization into the social-networking specific protocol, you are IMO unnecessarily restricting future applications.

[moritan]

I think Oauth2 is used for user authentication cf: http://tent.io/docs/app-auth (so based on email and standard).

But i don't understand most of your POST proxy idea...

[danielsiders]

Each Tent user is already responsible for maintaining a server, either by themselves or through a hosted service. These servers are accessible over HTTP and so already have URIs.

Users are more familiar with URIs as personal identifiers than they were a few years ago. i.e. http://twitter.com/danielsiders, http://facebook.com/daniel.siders, http://flavors.me/danielsiders, http://danielsiders.tumblr.com. Personal and vanity domains and subdomains are also widespread. Users change domains and domain seizures do happen. There is a simple protocol for updating a user's identity URI in these cases.

We intend (and expect others) to implement a lookup/directory system (possible Webfinger based) by email address, phone number, even former social addresses. i.e. I used to be @danielsiders on Twitter, do I operate a Tent server now?

Personal domains also make email addresses redundant. i.e. Daniel@Danielsiders.com or anything@steveklabnik.com. Increasingly URIs are used to identify persons or personas online. In the case of Tent users are required to maintain a server regardless, an email address-based identity system would be redundant.

[steveklabnik]

Ugh. Okay. I very, very, very strongly disagree, but this is your project, not mine. Thanks for the response.

[toulouse]

You're framing this in such a way that implies that people log in
using URIs and that users comfortable and familiar with this technique
are increasing. This is so wrong you risk alienating many users,
technical and nontechnical, entirely. URIs for identity is an awful
idea that will serve only to confuse.

[rrouse]

@danielsiders Are you sure? StackOverflow is about the only major site I know that actively uses OpenID (which does the URI style logins). How many users outside of the tech sector have used OpenID?

[steveklabnik]

I know I am a special case, but I accidentally let my openid provider expire (it was running on my own domain, and I moved hosting services) and so I haven't been able to log into SO for almost two years (iirc). Too much effort to bother putting one up again just to log into one service.

[moritan]

i'm don't see why uri should be use for login. Server could use what it want (pseudo , email,telepathy,..).
uri is only need for identify user through server, it's like a unique key. but maybe have i miss something ?

[navarr]

I agree that more thought should be given to this. Emails are more accurately tied to identities than URIs among the common.

The examples listed by @danielsiders are twitter, facebook, and tumblr. Tumblr being the closest to hitting the nail on the head. However, the fact of the matter is that people don't identify each other through those services based on their URL. Quite the opposite, they give a URL and a name. "I run "askthebutterflyfaerie" on Tumblr" or "Oh, I'm @Twinkletoes" and in the case of Facebook just "find me on Facebook."

Vanity URIs are used among the tech savvy, but have never truly caught on the way email addresses have, making this issue very relevant. As I was planning MSAP ("ReMAP") I considered doing social networking along with it - but emails would still be the primary identifier.

A user is much more likely to say "Oh, I'm fairyprincess@tent.io" than "Oh, I'm tent.io/fairyprincess." Why that is could be academically studied, but my best guess is because of how natural it is to say "at."

In conclusion, I urge you, @danielsiders, to reconsider. With the limited scope sharing, Tent.io could be a decentralized social network, and the replacement for email that people have been waiting for.

Post-Script:

Additionally, your other valid mention is personal domains. In which case, it would make just as much sense to remove the [user@]. "Yeah, I'm navarr.me" which would work the same as the URI.

Implementing Multiple methods of discovery, however, would not be absurd, would it?

[blaine]

@danielsiders I understand the attraction of using arbitrary URIs as
identifiers, but keep in mind things like the fact that many people use
Google to find GMail, Facebook, and Yahoo, because Google is the thing that
shows up on their browser when they open it. They're not going to
understand how to identify themselves, and more importantly, they won't be
able to remember or reason about their friends' identifiers.

There's a very famous quote from Antoine de Saint-Exupéry that says
"... perfection
is reached not when there is nothing left to add, but when there is nothing
left to take away."

It's incumbent on us to minimise complexity for users. Twitter, Facebook,
Tumblr, Instagram, etc – all the most popular social networks on the
internet – are incredibly simplistic in both their conception of identity
and their interaction models.

Building alternatives means building viable, popular alternatives. Let's
start with the minimum possible, and add features and concepts where
necessary. To my mind, after years of careful thought on the subject,
starting with email is the only viable option – everything else is simply
too complex for the vast majority of users.

On 23 August 2012 18:43, Daniel Siders notifications@github.com wrote:

Each Tent user is already responsible for maintaining a server, either by
themselves or through a hosted service. These servers are accessible over
HTTP and so already have URIs.

Users are more familiar with URIs as personal identifiers than they were a
few years ago. i.e. http://twitter.com/danielsiders,
http://facebook.com/daniel.siders, http://flavors.me/danielsiders,
http://danielsiders.tumblr.com. Personal and vanity domains and
subdomains are also widespread. Users change domains and domain seizures do
happen. There is a simple protocol for updating a user's identity URI in
these cases.

We intend (and expect others) to implement a lookup/directory system
(possible Webfinger based) by email address, phone number, even former
social addresses. i.e. I used to be @danielsidershttps://github.com/danielsiderson Twitter, do I operate a Tent server now?

Personal domains also make email addresses redundant. i.e.
Daniel@Danielsiders.com or anything@steveklabnik.com. Increasingly URIs
are used to identify persons or personas online. In the case of Tent users
are required to maintain a server regardless, an email address-based
identity system would be redundant.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-7975888.

[auxbuss]

I agree with email identities, as strongly as those above.

By coincidence, three days ago I was presenting to a group of business folk -- non-IT people, but most reasonably tech-savvy, across multiple businesses -- I didn't discover tent.io until the day after. They asked about the future of what they saw as convergence of "social media" and the problem of what we would call multiple identities. They started from email and moved from there to other services. They were most interested in bringing together people and their threads of conversation on a single topic from multiple places.

Using OStatus/StatusNet as my model to explain, they were delighted that identities were easy to grasp and consistent, in their view. Some openly commented, with relief, that tech folk hadn't invented another method. I hadn't thought about this issue much before then, but I felt very happy that the path chosen was surviving contact with future non-technical users.

The overriding message I took home that day was how strongly non-technical folk attached their online identity to their email address; I believe, more so than in the past.

[melvincarvalho]

IMHO, use of HTTP URIs (as recommended in the axioms of the WWW) is by far the strongest feature of tent.

If you're going to use email identifiers, just use Webfinger or OStatus. Though after 3 years they still havent fully decided how to identify a user, as evidenced by further discussion on the IETF list today. The biggest problem here is that HTTP was designed to link and discover, email was not.

Using HTTP URIs (highly recommended) is the most exciting thing about this protocol, aligns it to the web, and puts it on a par with ubiquitous technologies such as facebook open graph, linked data and the Web itself. And without wanting to state the obvious, it's one line of code to link a user profile to an email address. However, for the past few years no one has to date found a satifactory way to link an email address to the a user profile.

[steveklabnik]

Emails are URIs if you put the mailto: in front ;)

[webr3]

and if you want to use emails + webfinger you can use + specify + standardize a custom url param/variable for lookup, as RFC6415 makes provision for: e.g. https://gmail.com/.well-known/host-meta?user=joe@example.com

building on top of HTTP(+TLS), and indeed forcing TLS over the wire with https URIs easily outweighs any argument to use any other existing or new URI scheme as the primary form of identifier.

[blaine]

On 28 August 2012 01:11, melvincarvalho notifications@github.com wrote:

IMHO, use of HTTP URIs (as recommended in the axioms of the WWW) is by far
the strongest feature of tent.

If you're going to use email identifiers, just use Webfinger or OStatus.
Though after 3 years they still havent fully decided how to identify a
user, as evidenced by further discussion on the IETF list today. The
biggest problem is the HTTP was designed to link and discover, email was
not.

Using HTTP URIs (highly recommended) is the most exciting thing about this
protocol, aligns it to the web, and puts it on a par with ubiquitous
technologies such as facebook open graph, linked data and the Web itself.
And without wanting to state the obvious, it's one line of code to link a
user profile to an email address. However, for the past few years no one
has to date found a satifactory way to link an email address to the a user
profile.

Melvin, this isn't a question of the idealised technical properties of an
identifier. It's about humans, the living, breathing, thinking, feeling
people behind the keyboards. With all due respect, while I know you've
spent a long time thinking about the former, your website wouldn't get you
hired to deal with the latter.

The main reason that the decentralised social web has failed thus far is
that we've totally failed to involve product management and design people
in the process. As a result, we've ended up with purely theoretical
engineering solutions, instead of interesting and useful products.

It's a specious argument to say that email identifiers haven't been adopted
because Webfinger has seen very little adoption. The overwhelming majority
of websites use email identifiers alone as sign-in identifiers. Email
addresses also underly the majority of "friend finder" tools on social
networks (even if the users themselves don't realise this).

As I've remarked a number of times in various contexts, I don't care which
technology ultimately ends up being used. I came up with Webfinger, and
I've spent a lot of time helping to refine Webfinger, but I really don't
care if it "wins", because winning isn't about the protocol I (helped)
invent winning. Winning is users being able to interact in new ways with
more freedom, and developers being able to create those new means of
communication. Full stop. The technology only matters for the developers,
but must be driven entirely by the users' needs.

Please, I'm begging please, stop making technological arguments about this
subject. If you want to make an argument in defence of the user experience,
then by all means go ahead and do so, but stop with the harmful, irrelevant
technological debate.

For what it's worth, in an ideal world we'd use the names and faces we
already have – the only reason we're using email addresses is because on a
decentralised global network, we need to have globally unique identifiers.
Email addresses are a compromise, but a tolerable one.

[melvincarvalho]

@blaine Thanks for your response. Identifiers are important. Both architecturally and and from a user experience point of view. Having followed your work for a number of years, I know you feel passionately about this issue, and it's always great to hear your point of view. You've made huge contributions on this issue, and I try to follow your work and word closely.

I think there's a slight misunderstanding here, which I'll try and get to the bottom of.

Consider a relational database with a users table. One of the most important columns in the user table is the primary key. This is the fundamental element which defines the user. The importance of the primary key lies in it's ability to cross reference to other data items and also to other tables. You may think of this as the 'federation' system in the RDBMS that allows greater communication. The same principle applies to URIs but also means you can break out across the web to other systems and other RDBMS.

Now here is the critical point that i think has not been fully understood.

The primary key need never be exposed to the user, it is an architectural decision that glues things together. HTTP is the identifier of choice because the "follow your nose" and dereferancable property allows it to link to other data points, such as email, name, username etc. HTTP was designed to be linkable and has had good and growing success in adoption and tool chains.

Thus, in choosing a technical primary key, HTTP is superior to mailto: and much superior to the proposed acct: (webfinger) due to relative maturity.

Second key point.

This does not need to affect the user experience in any way. You can still log in with your email address, you can log in with a nickname, your own name or any other data in your system. It's exactly what facebook do with the open graph and it's not only technically sound, it's an awesome UX (especially with autocomplete), it scales and it has proven adoption.

Webfinger has a place in terms of making email identifiers more linkable, and I preferred your original version to what's currently there, but it's not necessary the ideal choice for the primary key of your system. It's certainly not the only choice available. It's not about winning or losing, it's about good choices to make life easier for developers, users and projects. We all have the same goal of interoperablity.

Fundamentally tent has made this decision, and I think it's with good thought and ought to be respected. It's what Tim Berners-Lee would advocate, it's what the W3C recommend and it's what facebook use. A well programmed UI can make things look completely transparent to the user and even allow login with email address. Once webfinger allows dereferncable email (which has taken too long but will hopefully be soon), it'll be that much stronger using the follow your nose pattern.

I hope that makes sense, and it's the reason im excited about tent.

[herestomwiththeweather]

i'm don't see why uri should be use for login. Server could use what it want (pseudo , email,telepathy,..).
uri is only need for identify user through server, it's like a unique key. but maybe have i miss something ?

@moritan yes, in theory, it seems a solution is good ol' edit profile -> update personal url...unless there's a use case this doesn't address.

[moritan]

@herestomwiththeweather : @melvincarvalho explain it in a relly better way than me.
personal url won't change. they are just primary key. The only case this URL change would be a migration between provider.
But it's the server stuff not user's.

I know, i'm not clear at all, but hopefully there person like @melvincarvalho ;)

[wilkie]

@melvincarvalho I have an issue that I do not believe uris such as the ones you propose solve. Basically, if I'm a human being and I want to let some other person follow me on a service, how would I give them the smallest, most easily identifiable identifier for me?

If the solution is to use a uri for identity that is an http uri, then that can be ok, from a technical point of view. But it is only a good identifier for identifying a user on a particular service. A master identifier to connect the services is still required and this identifier is NOT generally for machines. Let's look at an example:

I have two servers, (but maybe three in the future, who knows) where one server manages my microblogging service and the other my photo albums. How does another microblogging service find me? How can I have a single identity for both services? Well, I could have a third server or use one of the existing ones to represent 'me' everywhere. Then I could have a http uri (http://identi.ca/wilkie) and have this point to the photo server through some HTTP Link/rel somewhere. Cool. Cool. I mean, if you are building off of HTTP, you have an HTTP URI somewhere!

While that works from a technical point of view, it is awfully confusing. There are so many issues with a uri of this kind:

1. The uri scheme is a communication protocol that most users don't understand or think about.
2. Is it HTTPS? Do I allow my identity to be retrieved without SSL? Do users know the ramifications of the choice?
3. This is also my identi.ca feed profile... is that OK? Should I mix identity and service?
4. Can I change the service underneath the domain? (If I wanted to switch to a different microblogging software, would my uri change?)
5. Can I use a hosting service where I share a domain? Since domains offer a payment-barrier that may exclude many people.

The first two points are interesting, because while I can restrict what uris are used for identification to solve the rest of the points, the first two points are social in nature. Something we systems designers always forget about.

Most importantly, however, above all else (throw out the other things if you want!) is that it isn't human-readable as any daytime tv anchor reading a http address demonstrates.

We need an identifier that is consistent for everybody that serves as a uri that points to a set of http uris for the services the user attaches to that identity. We need one that is easy for users to give out simply by vocal communication without trouble. We need one that is easy to remember in case we don't have the chance to write it down (appears on a slide quickly, overheard, etc) These are problems real people face that an http uri alone does not solve.

"Email"-style addresses are actually quite good at all of these things and are a scheme that users are already familiar with. Bonus points if you build an email server. (already an existing federated protocol, so... WIN!)

[jonasschneider]

This also gives instant 'backwards compatibility'. I'm sokrates@tent.io. Have tent? Add me on Tent. Don't have Tent? Write me an e-mail. Tent discovery could just use the domain part and ask for something on tent.io/.well-known to find out the Tent endpoint.

(I believe this is what WebFinger does.)

[alexwright]

Maybe this is a case where implementers can be liberal in what you accept and conservative in what you send.

The spec would say for example, that entities are indeed a URI, but the UI implementation would be able to assume the entity be the tld part of an email address?

Edit: I'm personally in favour of a URI though. Passing arround something that looks a lot like an email address as an id leads to people emailing that, a la XMPP addresses. A URI, it's immediately apparent if the URI doesn't also work as a web address.

[jonasschneider]

(I'm diverging from what I said previously, I've thought it through.)

The notion of URI is quite misleading here. If a Tent URI is not a URL, it doesn't make sense at all, since it has to be a URN then, which is a name for a resource without a way to locate the resource. Not good when your goal is to locate the resource.

Tent obviously needs a locator. The question is whether a full-fledged URL or an email address (which, yes, can be prepended by mailto: to form a URL) gives the better user experience.
As @wilkie mentioned, since Tent specifies which protocol to use, the URL schema becomes redundant. So drop it.

The Tent canonical locator should therefore not include the protocol. tent.io/sokrates is quite enough, as @wilkie mentioned. Even better would be to limit the locator to just a domain, giving sokrates.tent.io. From a technical standpoint, the API is simpler as the root is always /, and from a human standpoint, a domain is more coherent than a domain+path as the nesting only goes in one direction. Subdomains nest deeper to the left, while paths nest deeper to the right. Please get rid of domain+path!

I personally would be quite happy with domain-only canonical locators. They feature no redundancy at all. The big drawback, however, is backwards compatibility. I propose the following long-term world-domination plan:

Current status: People usually provide a link to their homepage (equivalent to the canonical name) and an email address.

1. Use domain-only locators as described above as the canonical name for a Tent user.
2. Once it's possible to send & receive traditional email within Tent, implement a discovery method (webfinger or similar) to discover the canonical name for a given email address (i.e. for sokrates@tentmail.io query http://tentmail.io/.well-known/tentid/sokrates.

This would force nobody to publish anything new (which as we know, people don't) - aside from mentioning that they have Tent. Other tent users would use the canonical Tent name to discover the user, non-users can just write email to the address.

Once (and if) Tent gains widespread adoption, email usage will start to decline. As less and less people use email, more and more stop publishing the email address and only rely on the Tent name. Bam.

[ghost]

will it matter if i use persona/browserid just to login into my server implementation (one less of a password), but still use normal domain-based entity to operate with other servers?

[alexwright]

@noformnocontent no - That's outside the scope of the Tent spec. How servers authenticate the user is up to them.

[ghost]

hm, i'v changed my mind, emails shouldn't be involved in this at any level, the sooner we get rid of them the better

[wilkie]

This has nothing to do with emails. It's just a mechanism to determine the services available by a user of the system. You'll want a domain and a name, nothing more. Identifiers (URIs) of the form name@domain are what is being argued for over somebody being identified by a domain and path.

You want an identifier that uniquely identifies a person and is easy to remember. Remember, you'll give this out to people... you'll put it on a business card or a slide of a presentation. Your average person has good, valid associations with the name@domain identifier, which is why I support that method.

[ghost]

@wilkie sorry, i didn't ment anything about the topic, i just semi-replied to myself two comments ago, it's about how do i login into my own server. and pbly no, i wouln't put my login-name on a business card, esp. if it will be randomly generated 128 bytes string :)

[wilkie]

Right. This issue has nothing to do with authentication. People tend to mix that up, so I thought I'd point it out. :)

[michaelmd]

bad bad bad . nothing to know whether its http or https? .. can't assume either
(nor should it even assume ssl will be on port 443 because you can't hide an open port from other domains on the same box and broken https-before-http nonsense sneaking no code everywhere and lack of sni support in old browsers would break too much - as well as creating too much dependency on centralised verification by untrusted third parties) .

[bnb]

@michaelmd As far as I know, HTTPS is required as of 0.3 to solve this problem. To some degree, I know you can drop https:// because of that. I've been involved in a lot of the discussion surrounding that, and I don't think the port has ever mattered.