'acct' URI survey

[Eran Hammer-Lahav]

(I'll try this from another direction. I'm not trying to abolish the 'acct' URI, just better understand the collective wisdom, since clearly the lack of clarity on this has created a bunch of different expectations.)

- Does the format have to look like an email address? This identifier should never appear in front of a user. At the same time, many services use email addresses as the local identifier (Facebook, Google, etc.). The current syntax is strongly biased towards email providers. Its format also makes it more likely to find its way in front of users. Why not acct://twitter.com/hueniverse (for example)? Remember, this is an internal identifier.

- Profile pages work because there is a single way to interact with them (getting an HTML page and showing the human reader). How should client interact with 'acct' URIs in the context of human interaction? The less this is defined, the more confusing it will be for users.

- Is the 'acct' URI the canonical identifier of the account holder? Do we expect other protocols using WebFinger to maintain this identifier and assert it? If an internal mapping is allowed, which identifier should be used to link to the account? The canonical one or the 'acct' one?

- How do you think WebFinger and the 'acct' URI should be aligned with OpenID Connect as currently proposed?

- How do users authenticate that an 'acct' URI belongs to them? Consider the fact that authentication can be used for both accessing private data (delegation) as well as proving ownership.

EHL

[Blaine Cook]

On 27 May 2010 23:03, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
> - Does the format have to look like an email address?

Yes, it must look like an email address. I've made this argument many
times, but fundamentally the "user at place" grammar makes more sense
to *people* than the HTTP-style "place with person" grammar.

If we want identifiers for fine-grained "things you can't communicate
with", then HTTP URIs work just fine; if we're not going to use
email-like identifiers for content, why would we use http-like
identifiers for people?

> This identifier should never appear in front of a user.

The whole point is that this identifier is exactly what appears in
front of a user. Do you mean "the unique identifier that's returned by
a hypothetical OpenID Connect provider" should never appear in front
of a user?

> At the same time, many services use email addresses as the local identifier (Facebook, Google, etc.). The current syntax is strongly biased towards email providers. Its format also makes it more likely to find its way in front of users. Why not acct://twitter.com/hueniverse (for example)?

If Twitter (the only service today that has more than ~10 million
users that know their usernames, let alone their profile URLs) wants
to support Webfinger, they're free to do so – all they'd need to do is
have a clean way of dealing with the username/email namespace overlap,
which isn't difficult (particularly if they didn't offer email
services).

For everyone else, login is universally tied to an email address. I
honestly can't think of a single counter-example (before you say "Ahh!
But what about Twitter @anywhere and Facebook Connect?", remember that
both Twitter and Facebook use email addresses as identifiers, which
means that @anywhere and Facebook Connect are both tied to email
addresses as far as users are concerned).

> Remember, this is an internal identifier.

See above. I think this is a fundamentally external identifier.

> - Profile pages work because there is a single way to interact with them (getting an HTML page and showing the human reader). How should client interact with 'acct' URIs in the context of human interaction? The less this is defined, the more confusing it will be for users.

A "webfinger address" or "acct URI" is about being able to contact
someone. When a user types in "myfr...@example.com", the working
theory is that their software will do an LRDD lookup for
"myfr...@example.com" and offer the best way to contact
"myfr...@example.com".

If no LRDD profile exists, email is a legitimate fallback. While there
are many email providers that don't support webfinger (i.e.,
LRDD-discoverable profiles), the number of webfinger providers that
don't have an effective strategy for email is safely assumed to be
zero.

There's very little to define here in the specification sense, because
it's all about user experience and interface design. We can make
helpful suggestions, of course, but beyond the base discovery process
it's up to the designer.

> - Is the 'acct' URI the canonical identifier of the account holder? Do we expect other protocols using WebFinger to maintain this identifier and assert it? If an internal mapping is allowed, which identifier should be used to link to the account? The canonical one or the 'acct' one?

The acct URI. As John mentioned regarding the conversation about
OpenID Connect we had at IIW, the flow should be:

1. User provides an email-like identifier (b...@example.com).
2. RP performs discovery against email-like identifier
(example.com/.well-known/host-meta) to find the user's OpenID Connect
server (SP).
3. RP contacts SP, asking to authenticate b...@example.com
4. SP verifies that b...@example.com is logged in (however that happens).
5. SP provides RP with an assertion that b...@example.com successfully
logged in, and optionally remembers that RP is allowed to know when
bob is logged in from now on.

Now, there are several places that "OpenID Connect" could involve HTTP
URIs in this flow:

In Step #2, the result of the discovery process could be an HTTP URI
that uniquely identifies b...@example.com. This way, the SP could
authenticate bob without knowing which identifier bob provided to the
RP (even though that's kind of dumb). Without providing
'b...@example.com' in the authentication request (#3), though, the RP
can't guarantee that the identifier discovered in #2 is uniquely
bob's, which is problematic (mostly because I can't understand the
repercussions, which means it's unlikely that users will be able to).

Alternatively, in Step #4, the SP could provide the RP with an unique
identifier to use for future authentication requests. I'm not entirely
sure why that would be desirable, especially given that OAuth tokens
are already unique identifiers used for future authentication requests
(and, they're not HTTP URIs).

As far as I can tell, the use of HTTP/S URIs in the context of OpenID
Connect is purely a hold-over from OpenID. I'm biased, though, and
think that HTTP URIs should never be used for logins.

> - How do users authenticate that an 'acct' URI belongs to them? Consider the fact that authentication can be used for both accessing private data (delegation) as well as proving ownership.

See above. I claim that if:

1. A user's Webfinger profile provides a "login-provider" <link>

AND

2. Said login provider can assert to a relying party that the
webfinger account in question is logged in

THEN

3. The user has authenticated that an acct URI belongs to them.

This is exactly the same approach used by "password reminder" emails,
and other than the fact that unencrypted email communications are
susceptible to MITM attacks, I haven't heard a single objection to
this approach insofar as it is practiced today.

b.

[Eran Hammer-Lahav]

> -----Original Message-----
> From: webf...@googlegroups.com
> [mailto:webf...@googlegroups.com] On Behalf Of Blaine Cook
> Sent: Thursday, May 27, 2010 5:36 PM
> To: webf...@googlegroups.com
> Subject: Re: 'acct' URI survey
>
> On 27 May 2010 23:03, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
> > - Does the format have to look like an email address?
>
> Yes, it must look like an email address. I've made this argument many times,
> but fundamentally the "user at place" grammar makes more sense to
> *people* than the HTTP-style "place with person" grammar.
>
> If we want identifiers for fine-grained "things you can't communicate with",
> then HTTP URIs work just fine; if we're not going to use email-like identifiers
> for content, why would we use http-like identifiers for people?
>
> > This identifier should never appear in front of a user.
>
> The whole point is that this identifier is exactly what appears in front of a
> user. Do you mean "the unique identifier that's returned by a hypothetical
> OpenID Connect provider" should never appear in front of a user?

No. I mean the 'acct' URI. Browsers show the full URI to users. I'm arguing that this is an internal identifier and as such can be normalized from and to anything. If you are going to show this to people, they are going to expect this to be an email address.

> > At the same time, many services use email addresses as the local identifier
> (Facebook, Google, etc.). The current syntax is strongly biased towards email
> providers. Its format also makes it more likely to find its way in front of users.
> Why not acct://twitter.com/hueniverse (for example)?
>
> If Twitter (the only service today that has more than ~10 million users that
> know their usernames, let alone their profile URLs) wants to support
> Webfinger, they're free to do so – all they'd need to do is have a clean way of
> dealing with the username/email namespace overlap, which isn't difficult
> (particularly if they didn't offer email services).
>
> For everyone else, login is universally tied to an email address. I honestly
> can't think of a single counter-example (before you say "Ahh!
> But what about Twitter @anywhere and Facebook Connect?", remember
> that both Twitter and Facebook use email addresses as identifiers, which
> means that @anywhere and Facebook Connect are both tied to email
> addresses as far as users are concerned).

But they don't control those.

> > Remember, this is an internal identifier.
>
> See above. I think this is a fundamentally external identifier.
>
> > - Profile pages work because there is a single way to interact with them
> (getting an HTML page and showing the human reader). How should client
> interact with 'acct' URIs in the context of human interaction? The less this is
> defined, the more confusing it will be for users.
>
> A "webfinger address" or "acct URI" is about being able to contact someone.
> When a user types in "myfr...@example.com", the working theory is that
> their software will do an LRDD lookup for "myfr...@example.com" and
> offer the best way to contact "myfr...@example.com".
>
> If no LRDD profile exists, email is a legitimate fallback. While there are many
> email providers that don't support webfinger (i.e., LRDD-discoverable
> profiles), the number of webfinger providers that don't have an effective
> strategy for email is safely assumed to be zero.
>
> There's very little to define here in the specification sense, because it's all
> about user experience and interface design. We can make helpful
> suggestions, of course, but beyond the base discovery process it's up to the
> designer.

I think this 'sometimes an email address, sometimes not' is fundamentally broken. What do you ask people to type?

This is about the internal canonical identifier - the database key clients use to identify the user. It sounds to me like you want that to be an acct URI.

EHL

[Bob Wyman]

Eran Hammer-Lahav <er...@hueniverse.com> wrote:

> This identifier should never appear in front of a user

Why shouldn't users ever see WebFinger IDs? What utility is there in such a claim?

bob wyman

[Eran Hammer-Lahav]

Because the only reason why we created this work was to bootstrap something the user was *already* familiar with and was already using as an identifier – their email address. Showing users ‘hueni...@twitter.com’ or ‘acct:er...@hueniverse.com’ takes away all the value of this effort because it either misleads the user (no such email address) or confuses them (weird ‘acct:’ prefix before what must be an email address).

 

Arguments about XMPP using the same email-like identifiers are irrelevant outside the tech community (actually, the subset that uses Jabber).

 

I am convinced that exposing email-like identifiers that are not email addressed to users is going to cause nothing but confusion. If I logged into Twitter and saw “Welcome hueni...@twitter.com” even *I* would be confused. Not to mention, if I log into the NYTimes using my Twitter account and they welcomed me like that. The only valid options are: “Welcome hueniverse”, “Welcome Eran”, or “Welcome er...@hueniverse.com" (i.e. my real email which I consider my identifier).

 

This work is highly biased towards email providers (and for a good reason). I am not convinced there are real use cases for email-like identifiers that are not email addresses which is the point I was trying (but clearly failed) to make.

 

EHL

 

 

From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Bob Wyman
Sent: Thursday, May 27, 2010 10:40 PM
To: webf...@googlegroups.com
Subject: Re: 'acct' URI survey

 

Eran Hammer-Lahav <er...@hueniverse.com> wrote:

[John Panzer]

Do you have any data to back these usability assertions up?

I assert that the universe if interesting human+machine readable
identifiers is well covered by two patterns, x@y.z and y.z/x.

On Thursday, May 27, 2010, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
> Because the only reason why we created this work was to bootstrap something the user was *already* familiar with and was already using as an identifier – their email address. Showing users ‘hueni...@twitter.com’ or ‘acct:er...@hueniverse.com <acct%3Ae...@hueniverse.com>’ takes away all the value of this effort because it either misleads the user (no such email address) or confuses them (weird ‘acct:’ prefix before what must be an email address). Arguments about XMPP using the same email-like identifiers are irrelevant outside the tech community (actually, the subset that uses Jabber). I am convinced that exposing email-like identifiers that are not email addressed to users is going to cause nothing but confusion. If I logged into Twitter and saw “Welcome hueni...@twitter.com” even *I* would be confused. Not to mention, if I log into the NYTimes using my Twitter account and they welcomed me like that. The only valid options are: “Welcome hueniverse”, “Welcome Eran”, or “Welcome er...@hueniverse.com" <er...@hueniverse.com%22> (i.e. my real email which I consider my identifier). This work is highly biased towards email providers (and for a good reason). I am not convinced there are real use cases for email-like identifiers that are not email addresses which is the point I was trying (but clearly failed) to make. EHL  From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Bob Wyman

> Sent: Thursday, May 27, 2010 10:40 PM
> To: webf...@googlegroups.com

> Subject: Re: 'acct' URI survey Eran Hammer-Lahav <er...@hueniverse.com> wrote:> This identifier should never appear in front of a userWhy shouldn't users ever see WebFinger IDs? What utility is there in such a claim? bob wyman  On Thu, May 27, 2010 at 7:03 PM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:(I'll try this from another direction. I'm not trying to abolish the 'acct' URI, just better understand the collective wisdom, since clearly the lack of clarity on this has created a bunch of different expectations.)

>
> - Does the format have to look like an email address? This identifier should never appear in front of a user. At the same time, many services use email addresses as the local identifier (Facebook, Google, etc.). The current syntax is strongly biased towards email providers. Its format also makes it more likely to find its way in front of users. Why not acct://twitter.com/hueniverse (for example)? Remember, this is an internal identifier.
>
> - Profile pages work because there is a single way to interact with them (getting an HTML page and showing the human reader). How should client interact with 'acct' URIs in the context of human interaction? The less this is defined, the more confusing it will be for users.
>
> - Is the 'acct' URI the canonical identifier of the account holder? Do we expect other protocols using WebFinger to maintain this identifier and assert it? If an internal mapping is allowed, which identifier should be used to link to the account? The canonical one or the 'acct' one?
>
> - How do you think WebFinger and the 'acct' URI should be aligned with OpenID Connect as currently proposed?
>
> - How do users authenticate that an 'acct' URI belongs to them? Consider the fact that authentication can be used for both accessing private data (delegation) as well as proving ownership.
>
>
> EHL

--
--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Eran Hammer-Lahav]

Sure, and I assert that for web users, x@y.z is always assumed to be an email address and y.z/x is always assumed to be a web page of sorts. I don't think I need data to back my assertion that when someone sees x@y.z they automatically expect it to work as an email address (well, that it is an email address). I also don't need data to prove that if Twitter welcomed me with 'Hello hueni...@twitter.com' I would be very much confused by it (and I'm willing to bet that every geek seeing it will rush to test their cool new email address from Twitter).

When I conceived the 'acct' URI scheme, I modeled it after email addresses to make normalization or *email addresses* trivial (just stick 'acct:' in front of it). But I also clearly stated that I consider 'acct:er...@hueniverse.com@facebook.com' a perfectly valid account URI (which happens to be my Facebook account). This is why I explicitly defined it using the *right-most* '@' as the separator with the local part being any legal URI path character.

I'm sure we can all agree that 'acct:er...@hueniverse.com@facebook.com' doesn't look at all useful when presented to a web user. I am also willing to bet that Blaine will have a fit if he saw that anywhere (in human or machine documents) :-).

I don't have any data to back my usability assertions, but we can ask Blaine to ask his Grama what "Welcome blaine...@twitter.com" means to her.

EHL

> -----Original Message-----
> From: webf...@googlegroups.com
> [mailto:webf...@googlegroups.com] On Behalf Of John Panzer
> Sent: Thursday, May 27, 2010 11:29 PM
> To: webf...@googlegroups.com
> Subject: Re: 'acct' URI survey
>

> Do you have any data to back these usability assertions up?
>
> I assert that the universe if interesting human+machine readable identifiers
> is well covered by two patterns, x@y.z and y.z/x.
>
> On Thursday, May 27, 2010, Eran Hammer-Lahav <er...@hueniverse.com>
> wrote:
> > Because the only reason why we created this work was to bootstrap
> > something the user was *already* familiar with and was already using

> > as an identifier - their email address. Showing users

[Bob Wyman]

Having namespaced, easy-to-use names for people is one of a number of vital prerequisites to being able to build federated social and communications systems. Resistance to such naming conventions unwittingly contributes to making federation difficult if not impossible and encourages the current state of affairs which supports the creation of effective monopolies based of proprietary non-federated applications.

Email was the first "social" application to become "federated." A key element in allowing "anyone" to deploy an email server was breaking away from the non-namespaced, private directory-based naming systems typical of legacy systems and adopting a cross-system convention for namespaced names. It was precisely the requirement to support interworking between systems and federation that motivated the Jabber/XMPP developers to adopt the namespaced names for their JIDs. It is the same requirement that has motivated folk like Status.net in OStatus to adopt this naming convention for microblogging posts and replys. In the future, any federated social or communication system will have the same requirement.

We are seeing a blossoming of awareness of the utility of "social networking" applications and we're also finally seeing people begin to resist the idea that there will be only one implementation of any one class of application. More and more, we hear folk call for "Common open protocols, not common applications." Rather than being satisfied with Twitter as the only microblogging system, people want the same freedom they have with email -- the ability to build and deploy servers and applications that are optimized for their own requirements while still interworking in a federated network of other similar applications. They dream of Indenti.ca, Status.net, Buzz and maybe even Twitter supporting a common, system-independent method of addressing @replys... We see the same resistance to the monoculture of applications like Facebook -- people wish the freedom to implement their own social networks yet wish for their systems to work with others so that they can assemble large numbers of "small systems" into a larger system which is greater than the sum of its parts. They want to be able to connect to their friends without being subordinated to the ethics, privacy policies or business purposes of a single commercial entity. These efforts all require namespaced names. Names without namespaces are only useful in a world in which there is only one namespace -- the namespace maintained by whomever it is that maintains dominance and effective monopoly over a particular application class. If there is only one namespace, it is inevitable that there will be only one maintainer of that namespace.

Single namespace systems create "monopoly by design" as an inevitable side effect. WebFinger should be designed to support the best and most vital attributes of the open Internet. Rather than encourage and support the tendencies toward capture of application domains by single organizations that has become more common recently, WebFinger should ensure that it supports the same diversity of implementation that has been a cherished attribute of the Internet since its early days. Thus, WebFinger must provide easy-to-use, namespaced names. In today's world, "user@domain" is the easiest syntax for normal users and it provides the needed namespacing. It is what we should standardize on for naming of people in WebFinger.

bob wyman

[Bob Wyman]

Eran Hammer-Lahav <er...@hueniverse.com> wrote:

>  ask his Grama what "Welcome blaine...@twitter.com" means to her.

Come on! This is a strawman argument at best. The need and utility for providing the domain part exists only in contexts where there is ambiguity over what the domain is. If Blaine's Grama is a Twitter user and has a Twitter issued name, there is no need for Twitter to waste the screen space to show the "@twitter.com." bit. In fact, what Twitter probably should do is say "Welcome" followed by Grama's real name as stored in her Twitter profile. Or maybe show both: "Real Name (webfinger id)". However, if Blaine is using a Status.net microblogging system and wishes to @reply to his Grama, then he needs to know that she is "blaine...@twitter.com" because any replies addressed to "blaines_grama" might go to some random Grama on Status.net instead of to the one on Twitter. So Blain's Grama needs to tell him what her full ID is and be aware that this is how she is named to other people.

In any case, I'm using Gmail to prepare this message. Up at the top right of the page, it doesn't say "Bob Wyman," Rather, it gives my full Gmail address. Yes, I'm a techie and so I'm not bothered by this, but I assure you, that I've never heard anyone, techie or non-techie, suggest that they are "confused" by seeing their email address at the top of the Gmail pages...

bob wyman

[Eran Hammer-Lahav]

You must be joking. Of course you are not confused by your *email address* showing at the top of your *email program*! There is nothing out of context there. But how should the NYTime welcome a user using their Twitter account to log into the site?

 

The only way Grama will be able to grasp “blaine...@twitter.com” is if it was actually an email account. Why? Because what else could it be?! Ask anyone you want, it *is* an email address. Now, users on other microblogging sites might be used to this hack by now because they really want to interact with Twitter users, but that’s an insignificant number of mostly geeks.

 

I’m not trying to burst your utopian federated social web vision. I think my work speaks for itself. But expecting people to suddenly get that something@somewhere isn’t always an email address (and that there is no real way of knowing other than trying to send it a message) is unrealistic.

 

EHL

 

[John Panzer]

Demonstrably false.

is unrealistic.
>

So we now have two opposing assertions with the same amount of ux data
provided for each.

By the way, at AOL for years they believed nobody would understand
more than a simple 'screen name'. Then they believed nobody would
understand using a full email address to log in. These fears proved
unfounded. Grandma gets it.

[Dan Brickley]

On Fri, May 28, 2010 at 9:17 AM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:

You must be joking. Of course you are not confused by your *email address* showing at the top of your *email program*! There is nothing out of context there. But how should the NYTime welcome a user using their Twitter account to log into the site?

 

The only way Grama will be able to grasp “blaine...@twitter.com” is if it was actually an email account. Why? Because what else could it be?! Ask anyone you want, it *is* an email address.

Ok, what if we rolled with it, and said that these actually would be emailable addresses? Is that an impossible burden to put on webfinger implementors? Now they *don't* (can't) be the users current / main / private email address. If dan.br...@example.com is my private address, I want it to stay private. But I could reasonably be asked to create a second public email address "just for connecting with". What happens to mail that's sent to it? (including gigabytes / year of spam). Maybe it all bounces, or returns HTML-mail webfinger description of the account. Maybe some gets through based on [insert crypto-based fantasies about signed email and trust here].

What I'm getting at, is that the cost of saying it is *an* email address isn't clear. Surely it can't be their main existing secret address. But the idea of people having multiple email addresses is by now very well established. "Send it to my work address", "I don't use my hotmail one any more", "I've forgotten which address he prefers these days", "I don't think he reads that one any more", etc.

Scope can be a wonderful thing, and slipping into "let's fix the email-is-broken problem" isn't something to do lightly.

What are the main costs, if these things are to be considered email addresses?

Costs to the provider: twitter & suchlike would have to have systems in place to accept SMTP to dan...@twitter.com;

Costs to account holder: remembering which is which, if private email and public 'connect' email/webfinger identifiers look similar

Costs to others: mixups like sending mail to an inferred 'email' address; for example I apparently have a hotmail address, thanks to having signed up to MSN chat. Periodically I log in and find ancient missed messages there. I've never advertised this 'email address', but it somehow leaked out through the MSN chat software UI. I'd expect similar with webfinger, emailable or not.

Couldn't these addresses be made emailable, even if they just returned a helpful 'this is not the email account you're looking for' message?

Dan

[Blaine Cook]

On 28 May 2010 12:19, Dan Brickley <dan...@danbri.org> wrote:
> Couldn't these addresses be made emailable, even if they just returned a
> helpful 'this is not the email account you're looking for' message?
> Dan

I agree 100% with Dan's and John's statements here.

Dan's suggestion here is exactly what I was getting at when suggesting
that Twitter could add Webfinger support without necessarily adding
email support.

It works in reverse, too – let's assume for a moment that in addition
to returning a message that says "this is not the email account you're
looking for", Twitter is able to identify friends of the addressed.
For example, b...@example.com is friends with sa...@example.com. Sally
sends an email to bobex...@twitter.com, and Twitter replies "Oh,
sorry! This isn't an email address. But, you can contact bob at his
canonical address of b...@example.com."

That same approach can be applied to an "authenticated webfinger
lookup" (/me waves hands, but only slightly).

b.

[Eran Hammer-Lahav]

I have no problem with that. It solves my problem (and BTW, a simple forward to the real address is as simple, and all the normal spam filters will apply).

So now we have this account identifier that looks like an email address and have some email capabilities depending on how it is implemented. What are the restrictions on its structure, given that now you want to be able to display it as-is, with or without the 'acct' URI prefix (well, maybe you don't but other people here do)?

Only one '@' sign? Allow more but parse on the right-most?

Also, is there a reason why it should not allow dual format? That is both:

acct:user@host
acct:host/user

So you can use the second one when it is clearly not email-enabled, but still using a very familiar format (i.e. Twitter and Facebook). I'm just asking.

---

I also need some suggestions for prose on how to define/describe this URI scheme. What does it *mean* and how does it relate to *mailto*. I got some have baked ideas on how to explain this, but it would be useful if others write their 1-3 paragraphs and shared it here so we can compare note.

We are clearly thinking about this in slightly different ways.

EHL


> -----Original Message-----
> From: webf...@googlegroups.com
> [mailto:webf...@googlegroups.com] On Behalf Of Blaine Cook
> Sent: Friday, May 28, 2010 4:28 AM
> To: webf...@googlegroups.com
> Subject: Re: 'acct' URI survey
>

[Bob Wyman]

If we insist that everything that looks like email address IS an email address, that means that we continue the current ridiculous situation that allows anyone who knows my name to spam me. Given that WebFinger ids are going to be useful in a wide variety of situations other than email, this means that the more I use WebFinger, the more susceptible I am to email spam. The linkage between what will increasingly become my "name" on the Internet and the ability to send me unsolicited and unwanted mail is not a good one...

Ideally, we'll see a move away from application specific names and an acceptance of globally useful names. Thus, in the ideal world, my "name" on Facebook, Twitter and Buzz would all be the same. I would be globally recognizable in a vast number of contexts yet exposing my identity in all these environments would not necessarily expose my email inbox as a side effect.

If we don't have globally useful names, and if the use of a name implies the presence of an inbox as a side-effect, then I'm going to be hesitant about using new services since they will be compelled to create "yet-another-inbox" for me. This hesitancy will result in a distinct advantage to "first mover" and dominant application providers since it essentially creates a barrier to mobility and thus a barrier to entry for new entrants in the application domain. Thus, an insistence on email being linked to a name is essentially a force which encourages and supports the establishment of application domain monopolies -- monopoly by design. This is not good.

I wonder what the implication might be of having lots of email inboxes lying around that I don't use. Whether or not it is the case today, I think it doesn't take too much imagination to see that in the future (near or far) sending an email will probably be considered a legal form of "adequate notification" for a variety of purposes. (Remember, the standards we make today must/will last for a long time.) Thus, we're likely to see that the resistance to inbox proliferation which exists today simply because of nuisance issues (need to maintain forwarding, etc.) will one day be strengthened by legal concerns.

Today's email "forwarding" system is completely broken. While it often works, the problem is that creating an email account establishes an essentially permanent relationship between an addressee and an email provider (i.e. lock-in) and creates tremendous resistance to mobility. Thus, incumbent providers are, as a side effect of  the protocols, given a distinct business advantage. In a more ideal world, I would have a relatively permanent personal identifier that would be understood to map temporarily to one or another "email" address. In fact, ideally, my correspondents would never even know what my real email address was and the mapping between my public name and my email address at any time would be completely under MY control -- without the need for my email provider to be involved. (i.e. Once WebFinger IDs are popularized, people would send emails to me by indirecting through my WebFinger ID -- if they were authorized, and not by specifying my actual id. Even if their email clients didn't support WebFinger, XRDs, etc. they would still have a mechanism to track down my new email address if they ever get an "recipient-unknown" message.)

bob wyman

[Brad Fitzpatrick]

Replying to this survey late, as I was out yesterday, but...

On Thu, May 27, 2010 at 4:03 PM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:

(I'll try this from another direction. I'm not trying to abolish the 'acct' URI, just better understand the collective wisdom, since clearly the lack of clarity on this has created a bunch of different expectations.)

- Does the format have to look like an email address? This identifier should never appear in front of a user. At the same time, many services use email addresses as the local identifier (Facebook, Google, etc.). The current syntax is strongly biased towards email providers. Its format also makes it more likely to find its way in front of users. Why not acct://twitter.com/hueniverse (for example)? Remember, this is an internal identifier.

I don't care how they look.  Not having an "@" sign might actually be good.  Apparently a gigantic unnamed social networking site doesn't want to do WebFinger because the press will freak out and think they're doing email support, if they see f...@unnamedsite.com anywhere.

But I want something machine-readable to represent accounts (e.g. Twitter and Facebook don't have emails, but they have accounts) and I want to be able to reference them in machine-readable ways from e.g. Buzz.

User types:  "Today @" (auto-complete dialog opens, user types "Bec" and auto-completes "Becky Martin") and user keeps type "went to the mall.  It was fun."  The user never typed a webfinger identifier (we auto-completed it from their address book and friends on sites elsewhere), but machine-readable we'll have a way to do references in our activity streams and whatnot, and in the future be able to do a webfinger lookup on those remote sites to find their "vanity pingback" service URL to tell them that they've been mentioned somewhere (perhaps on a site they don't even use....)

- Profile pages work because there is a single way to interact with them (getting an HTML page and showing the human reader). How should client interact with 'acct' URIs in the context of human interaction? The less this is defined, the more confusing it will be for users.

You see what Mozilla Labs made Firefox do with them?  Something like Blaine's webfinger.org demo page, showing what was discovered about that account.

[Blaine Cook]

On 28 May 2010 19:43, Brad Fitzpatrick <brad...@google.com> wrote:
> I don't care how they look.  Not having an "@" sign might actually be good.
>  Apparently a gigantic unnamed social networking site doesn't want to do
> WebFinger because the press will freak out and think they're doing email
> support, if they see f...@unnamedsite.com anywhere.

I honestly don't care what they look like, improbable as that may
sound. I want something that works.

Remember when another, totally different, unnamed gigantic social
networking site added support for the x.y/z format[1]? Yeah, me
neither.

b.

[1] http://techcrunch.com/2009/06/09/you-have-three-days-to-pick-your-facebook-vanity-url/

[Eran Hammer-Lahav]

How do you feel about allowing both formats (@ and /) since they are trivial to detect and convert?

 

EHL

 

From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Brad Fitzpatrick
Sent: Friday, May 28, 2010 11:43 AM
To: webf...@googlegroups.com
Subject: Re: 'acct' URI survey

 

Replying to this survey late, as I was out yesterday, but...

[Dan Brickley]

On Fri, May 28, 2010 at 8:25 PM, Bob Wyman <b...@wyman.us> wrote:
> If we insist that everything that looks like email address IS an email
> address, that means that we continue the current ridiculous situation that
> allows anyone who knows my name to spam me.

Hey, slow down! that's a big leap. Forwarding was mentioned as one
possible scenario, but my original proposal was careful to say that
making the identifier email-capable could be as basic as having a
'vacation message'-style responder saying "this is not the email
address you're looking for. Many people have multiple email accounts
for multiple purposes. Some maintain a work / non-work distinction, or
a webmail / pop distinction, or just accumulate a collection over time
as they come free with various services. Having another potentially
emailable address as a side effect isn't too complex a concept to
communicate. And even if it is effectively de-activated in many cases,
they would still be email-ish enough to count as email accounts rather
than "something completely different but identified with email-style
IDs".

> Given that WebFinger ids are
> going to be useful in a wide variety of situations other than email, this
> means that the more I use WebFinger, the more susceptible I am to email
> spam.

Only if your service provider or yourself configure mail send to the
webfinger ID to redirect it to your real acount. Only those folk with
robust spam filtering and whose real/main email addresses are public
would likely want this.

> The linkage between what will increasingly become my "name" on the
> Internet and the ability to send me unsolicited and unwanted mail is not a
> good one...

Agreed.

> Ideally, we'll see a move away from application specific names and an
> acceptance of globally useful names. Thus, in the ideal world, my "name" on
> Facebook, Twitter and Buzz would all be the same. I would be globally
> recognizable in a vast number of contexts yet exposing my identity in all
> these environments would not necessarily expose my email inbox as a side
> effect.

Yup. And ideally ownership/control of the dns names used would be more
widespread, but that's another matter.

> If we don't have globally useful names, and if the use of a name implies the
> presence of an inbox as a side-effect, then I'm going to be hesitant about
> using new services since they will be compelled to create
> "yet-another-inbox" for me.

Something being an email address does not guarantee that mail sent to
it will end up in a user-facing inbox.

For eg. dan...@w3.org is an email address; W3C are still good enough
to forward it to me, but at some point they'll probably stop. Unless
you consider /dev/null an inbox, even in the purely email world
(forgetting webfinger for a second) this doesn't follow.

Now how "bad" can an email service be before the ID stops counting as
a 'real' email address? I don't know. It's kind of an angels/pinheads
question, but also a practical question to leave to implementors. The
main thing is that nothing in webfinger should depend on it being used
for email, or on SMTP-based services. But to users we can explain it
as a special extra email address that's only used for [explanation of
webfinger etc goes here].

> I wonder what the implication might be of having lots of email inboxes lying
> around that I don't use. Whether or not it is the case today, I think it
> doesn't take too much imagination to see that in the future (near or far)
> sending an email will probably be considered a legal form of "adequate
> notification" for a variety of purposes.

The more people online and sending emails, the less plausible it is
that any mortal human can keep up with their inboxes.

> (Remember, the standards we make
> today must/will last for a long time.) Thus, we're likely to see that the
> resistance to inbox proliferation which exists today simply because of
> nuisance issues (need to maintain forwarding, etc.) will one day be
> strengthened by legal concerns.

The reminder of long-term impact of standards is fair enough. I'm not
buying the other argument, but since we're already talking past each
other somewhat (nobody says this needs to be a real user-facing email
account, just emailable) I don't see an issue here. It's
not-being-their-main-inbox-ness could always be made explicit via
webfinger anyway, so the legally minded didn't accidentally send
things into a black hole.

> Today's email "forwarding" system is completely broken. While it often
> works, the problem is that creating an email account establishes an
> essentially permanent relationship between an addressee and an email
> provider (i.e. lock-in) and creates tremendous resistance to mobility.

Yup. I think we'll only see progress on that when domain name
ownership and management becomes a more user-friendly business.

cheers,

Dan

[Blaine Cook]

On 28 May 2010 19:25, Bob Wyman <b...@wyman.us> wrote:
> If we insist that everything that looks like email address IS an email
> address, that means that we continue the current ridiculous situation that
> allows anyone who knows my name to spam me. Given that WebFinger ids are
> going to be useful in a wide variety of situations other than email, this
> means that the more I use WebFinger, the more susceptible I am to email
> spam. The linkage between what will increasingly become my "name" on the
> Internet and the ability to send me unsolicited and unwanted mail is not a
> good one...

I don't think anyone's insisting that everything that looks like an
email address is or must be an email address; just that, for now,
users will be more comfortable with using addresses that ARE email
addresses.

Keep in mind that spam is largely enabled by the fact that the
deployed infrastructure of SMTP servers has no reliable way of
establishing the identity of a sender. Exhibit 1:

_spf.google.com descriptive text "v=spf1 ip4:216.239.32.0/19
ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18
ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16
ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"

Google's SPF record has, at the end, "?all", which means "Ignore all
that spam prevention stuff you just parsed, basically it's meaningless
because anyone could be sending email with this from address."

With an LRDD infrastructure, we get DNS for People. Which means we get
SPF and DomainKeys for people. Which means we can drop messages with
forged headers. It also means we can reliably move to whitelist-based
systems (which we've already done, essentially - facebook and twitter
are both whitelist-based systems).

We can also augment SMTP systems to authenticate the *user*, rather
than the *server*. So I see this sort of discoverability as a net win
for email.

b.

[Blaine Cook]

On 28 May 2010 19:55, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
> How do you feel about allowing both formats (@ and /) since they are trivial
> to detect and convert?

Pick one. This fucking bullshit in specifications giving users and
developers the choice is retarded.

http://37signals.com/svn/posts/2335-the-art-of-taking-things-away

How are we going to explain to users "well, you can use @ or /, so
your twitter address is either bob/twitter.com or b...@twitter.com,
y'know, take your pick."?

Seriously, this stuff matters.

It's about cognitive psychology, not ease of parsing.
It's about linguistics and pattern recognition, not purity of the holy
altar of the URI.

Pick one and be done with it. But do so knowing that "x@y.z" is a
widely-recognised format that is parsed as "person @ brand" – "y.z/x"
is a virtually never-used format that is parsed as "brand". If you're
dealing with someone really smart, it's parsed as "brand with some
shit at the end".

To clarify my point on this:

- I *don't* care what the identifier looks like.
- I *do* care that the identifier is successful.
- I have not seen *any* proposals that are not problematic in some way.
- Email-like identifiers are, in my opinion for the reasons stated
above, the least problematic.
- We need to pick ONE. Users will not adopt MANY.

b.

[Martin Atkins]

On 05/28/2010 11:55 AM, Eran Hammer-Lahav wrote:
> How do you feel about allowing both formats (@ and /) since they are
> trivial to detect and convert?
>

While I don't think this is a major consideration for the use-case at
hand, I just wanted to draw attention to the fact that example.com/foo
and f...@example.com are both valid XMPP identifiers, as is
f...@example.com/bar.

Since the focus for acct: is identifying people, and the example.com and
example.com/foo forms are generally for addressing bits of software,
this is probably okay.

[Bob Wyman]

Dan Brickley <dan...@danbri.org> wrote:

> we're already talking past each other somewhat

> (nobody says this needs to be a real user-facing email
> account, just emailable) 

I'm sorry if we're "talking past each other"... If that is the case, I'm clearly not understanding something.

Can you say a bit more about what it means to have an email address that is "emailable" but that isn't a "real user-facing email?" What are the attributes of an "emailable" email account? How is such an account different from an "real user-facing email account?"

> we'll only see progress on that when

> domain name ownership and management

> becomes a more user-friendly business.

One of the reasons I *really* like WebFinger is that it will, in fact, provide much of the benefit that we might get from a more user-friendly system of domain name ownership and management... As Blaine suggests in another email, WebFinger + Friends can be seen as a form of "DNS for People." What am I missing? Why do we need to modify DNS if we can accomplish, one level lower, much the same via WebFinger, etc.?

bob wyman

[Blaine Cook]

I agree 100% with Dan's comments here.

[Blaine Cook]

On 28 May 2010 20:11, Martin Atkins <ma...@degeneration.co.uk> wrote:
> While I don't think this is a major consideration for the use-case at hand,
> I just wanted to draw attention to the fact that example.com/foo and
> f...@example.com are both valid XMPP identifiers, as is f...@example.com/bar.

Just to clarify here, xmpp:example.com/foo != xmpp:f...@example.com

xmpp:example.com/foo means "the temporary resource or connection
instance 'foo' associated with the bare JID at host 'example.com'"

xmpp:f...@example.com means "the user 'foo' at host 'example.com'"

xmpp:f...@example.com/bar means "the temporary resource or connection
instance 'bar' associated with the user 'foo' at host 'example.com'"

> Since the focus for acct: is identifying people, and the example.com and
> example.com/foo forms are generally for addressing bits of software, this is
> probably okay.

The XMPP people would hunt down anyone who started promoting
"example.com/foo" as an identifier for a person. You *could* do it
[with heavy modification of existing xmpp servers], it would work, but
it would [severely] break their security and permissions model. No
XMPP client would be able to log in a server that did such things,
though.

b.

[Eric Mill]

x.y/z seems far more problematic than z@x.y - x.y/z implies the very
URL structure of the website in question, and not all social networks
should be obligated to provide short handle-based URLs for users. The
implication of URL structure seems to me to be less revocable than
z@x.y's implication of an email address.

Federated cross-domain mentions using Webfinger was, for me, the most
inspiring part of the social web talks I saw at Google I/O. If we
need to start blurring the one-to-one relationship between @ symbols
and email addresses, so be it. I would strongly recommend we also not
ask Webfinger providers to support SMTP, even for an auto-responder
functionality, if only so that the barrier to participating in our
utopian federated social web vision is as low as possible.

-- Eric

[Dan Brickley]

On Fri, May 28, 2010 at 9:14 PM, Bob Wyman <b...@wyman.us> wrote:
> Dan Brickley <dan...@danbri.org> wrote:
>> we're already talking past each other somewhat
>> (nobody says this needs to be a real user-facing email
>> account, just emailable)
> I'm sorry if we're "talking past each other"... If that is the case, I'm clearly not understanding something.

And I'm clearly not being clear. Let's try to fix that.

> Can you say a bit more about what it means to have an email address that is
> "emailable" but that isn't a "real user-facing email?" What are the
> attributes of an "emailable" email account? How is such an account different
> from an "real user-facing email account?"

It's emailable in the sense that you can connect and send stuff via SMTP.

The idea of having multiple email addresses is not new or strange.
Even multiple addresses from the same higher-level user account. The
idea of email addresses being configured as 'disabled' / 'bounce
everything' / 'send everything straight to trash' is not particularly
hard for users to grasp.

So all I'm saying is that we don't need to say mysteriously to users
"Webfinger IDs look like email addresses, but they aren't really,
they're something different". We just say "Webfinger IDs are a special
kind of email address that are designed just to use as identifiers;
they don't replace your main email address, since you may want to keep
those private".

This is mostly spin / narrative, and in practice if a provider didn't
turn on SMTP nothing would break since Webfinger ignores it. But it
allows us to replace an "it's like an email but it isn't an email"
explanation with "it's an extra email address". I think there are some
interesting ways in which this kind of social Web infrastructure could
help fix the email / spam situation (Blaine touched on some of that),
and the approach I'm suggesting would leave the door nicely open for
such things, without requiring them.

>> we'll only see progress on that when
>> domain name ownership and management
>> becomes a more user-friendly business.
> One of the reasons I *really* like WebFinger is that it will, in fact,
> provide much of the benefit that we might get from a more user-friendly
> system of domain name ownership and management... As Blaine suggests in
> another email, WebFinger + Friends can be seen as a form of "DNS for
> People." What am I missing? Why do we need to modify DNS if we can
> accomplish, one level lower, much the same via WebFinger, etc.?

I'd rather be dan...@danbri.org than dan...@twitter.com or
@facebook.com, even if I love those services. If I don't buy and
manage my own domain, I end up entangled with services that might go
bad in a few years. I can't see how to avoid DNS there...

cheers,

Dan

[Eran Hammer-Lahav]

Ok. Blaine is -1 for options... :-)

EHL

> -----Original Message-----
> From: webf...@googlegroups.com
> [mailto:webf...@googlegroups.com] On Behalf Of Blaine Cook
> Sent: Friday, May 28, 2010 12:11 PM
> To: webf...@googlegroups.com
> Subject: Re: 'acct' URI survey
>

[Bob Wyman]

Dan Brickley <dan...@danbri.org> wrote:

> This is mostly spin / narrative, and in

> practice if a provider didn't turn on SMTP

> nothing would break since Webfinger ignores 

What displeases me is the suggestion that if I were to provide a WebFinger service to all "Wyman"s in the US, I would have to provide SMTP service and/or mail forwarding for all of those people. I can't afford it and don't want the hassle of running such a service. I'd rather just host the profiles and XRDs that could be used to discover Wyman's actual email addresses. But, if you're saying that it is "ok" to have SMTP turned off or disabled, then I think we have no conflict. It is just spin. Sometimes an id is useful as an email address and sometimes it isn't.

> I'd rather be dan...@danbri.org than dan...@twitter.com

> or @facebook.com, even if I love those services.  If I don't

> buy and manage my own domain, I end up entangled

> with services that might go bad in a few years.

Too bad your last name isn't "Wyman"... If it was, I'd be able to offer you a nice, service-independent WebFinger/OpenId solution...

bob wyman

[John Panzer]

No strong preference on syntactic sugar. But it should be painted blue.

I also recommend an SMTP reject with a Webfinger advertisement in it
for people who don't want their IDs to be emailable. I volunteer to
set up a cloud service anyone can point an MX record at.

On Friday, May 28, 2010, Bob Wyman <b...@wyman.us> wrote:
> Dan Brickley <dan...@danbri.org> wrote:> This is mostly spin / narrative, and in

>> practice if a provider didn't turn on SMTP> nothing would break since Webfinger ignores
> What displeases me is the suggestion that if I were to provide a WebFinger service to all "Wyman"s in the US, I would have to provide SMTP service and/or mail forwarding for all of those people. I can't afford it and don't want the hassle of running such a service. I'd rather just host the profiles and XRDs that could be used to discover Wyman's actual email addresses. But, if you're saying that it is "ok" to have SMTP turned off or disabled, then I think we have no conflict. It is just spin. Sometimes an id is useful as an email address and sometimes it isn't.
>

>> I'd rather be dan...@danbri.org than dan...@twitter.com <dan...@twitter.com>> or @facebook.com, even if I love those services.  If I don't
>> buy and manage my own domain, I end up entangled> with services that might go bad in a few years.Too bad your last name isn't "Wyman"... If it was, I'd be able to offer you a nice, service-independent WebFinger/OpenId solution...

--

[Dan Brickley]

On Fri, May 28, 2010 at 10:50 PM, John Panzer <jpa...@google.com> wrote:
> No strong preference on syntactic sugar. But it should be painted blue.
>
> I also recommend an SMTP reject with a Webfinger advertisement in it
> for people who don't want their IDs to be emailable.

Would the response be flatly identical across the service, or custom per ID?

(I kind of like idea of XHTML+RDFa emailed responses, but won't push
that for now)

> I volunteer to set up a cloud service anyone can point an MX record at.

Great :)

Do you have any sense for the volume of spam you'd have to deal with
with, and what level of commitment it's feasible to take on?

cheers,

Dan

[John Panzer]

This would be a static-string response for all recipients for a given domain (MX record points at a set of IPs).  Probably an error on RCPT TO similar to what you might get for an unknown user:  

550 5.1.1 <j...@example.org> Not receiving email.  This is a Webfinger address; see http://webfinger.org for details

...with a fast timeout for clients who take a long time to send a RCPT TO.

It would be a highly parallelizable service.  And the top IP's hitting it with connections would be good candidates for input into a spam blacklist :).

If someone wants a domain that has both email addresses and Webfinger IDs, they'd need to do something more complicated.  Of course they're already running a mail service.

We could probably figure out something nice for people who outsource their MX records to GMail at least...

 

cheers,

Dan