The Case for a Simplification of Webfinger
Melvin Carvalho
The adoption, in particular, of wefinger has been impressive. But have there been lessons learnt over the past two years?
1. I think we've seen an acceleration in the shift away from XML to JSON. Some say syntax is not important, and is covered by MIME types anyway, but I do think JSON is what developers like working with now, that's a trend that's set to stay (famous last words).
2. Almost no one understands the difference between mailto: acct: and a 'normal' email address. Although this is critical to the spec and web scalability, I think that the subtlety is going to be too much for the average developer and potentially cause confusion for years to come. The question arises, do we even need acct: ?
Possible Simplification
=================
In a nutshell why not take :
j...@gmail.com and translate to -> gmail.com/@/joe
Serve it as JSON, and we're pretty much done (ive skipped a couple of details for brevity).
We have a few world class, scalable, JSON formats now that we didnt have 2 years ago.
Analysis
=========
Pros: simplicity, remove need for acct:
Cons: involves changing the spec, developer tools, less flexibility of path
I must admit the last point is a biggie ... so I'm just throwing this out there, im undecided in my mind whether this will fly.
Given that much of the webfinger support is still a work in progress, would it be worth considering weighing the pros and cons based on from what we've learnt?
Bob Wyman
Webfinger has come a long way in the last 2 years. Having reviewed the latest spec I'm convinced that it's a high quality piece of writing that fills a very important gap.
The adoption, in particular, of wefinger has been impressive. But have there been lessons learnt over the past two years?
1. I think we've seen an acceleration in the shift away from XML to JSON. Some say syntax is not important, and is covered by MIME types anyway, but I do think JSON is what developers like working with now, that's a trend that's set to stay (famous last words).
2. Almost no one understands the difference between mailto: acct: and a 'normal' email address.
Although this is critical to the spec and web scalability, I think that the subtlety is going to be too much for the average developer and potentially cause confusion for years to come. The question arises, do we even need acct: ?
Possible Simplification
=================
In a nutshell why not take :
j...@gmail.com and translate to -> gmail.com/@/joe
Pelle Wessman
1. I think we've seen an acceleration in the shift away from XML to JSON. Some say syntax is not important, and is covered by MIME types anyway, but I do think JSON is what developers like working with now, that's a trend that's set to stay (famous last words).
Something that many seems to forget, perhaps you as well, when talking about WebFinger is that WebFinger itself isn't really specifying much - it almost completely relies on the more generic "Web Host Metadata" specification.
The "Web Host Metadata" specification defines how one can specify discoverable properties and links in a document separate from the page itself. WebFinger just defines what URI to use when looking up a specific user with a "Web Host Metadata" defined document - almost everything else is defined by the "Web Host Metadata" specification and applies to all kinds of URI:s.
This is relevant when it comes to JSON because the "Web Host Metadata" specification has evolved in parallel with WebFinger and before it got to a complete finalized specification it described how to express the XRD (which is from an even more generic specification than "Web Host Metadata") in JSON - called JRD.
So - since WebFinger is just a thin layer on top of the "Web Host Metadata" specification and it in turn already supports JSON that means that WebFinger itself also supports JSON.
Here's an example of a yet unannounced JSON-webfinger: https://flattr.com/xrd/lrdd.json?uri=acct%3Avoxpelli%40flattr.com
/ Pelle
Eric Mill
On Sun, Feb 26, 2012 at 5:07 AM, Melvin Carvalho <melvinc...@gmail.com> wrote:Webfinger has come a long way in the last 2 years. Having reviewed the latest spec I'm convinced that it's a high quality piece of writing that fills a very important gap.
The adoption, in particular, of wefinger has been impressive. But have there been lessons learnt over the past two years?
1. I think we've seen an acceleration in the shift away from XML to JSON. Some say syntax is not important, and is covered by MIME types anyway, but I do think JSON is what developers like working with now, that's a trend that's set to stay (famous last words).
2. Almost no one understands the difference between mailto: acct: and a 'normal' email address.
Errr... So what? What I don't understand is why it might be important if large percentages of people don't understand the differences... Remember please that "normal" folk are never going to understand the subtle nuances of much of what we do. The important question isn't "Do they understand?" but rather: "Does it matter if they understand?" What harm do we fear will come to users who don't understand the subtle differences here?
In a nutshell why not take :
j...@gmail.com and translate to -> gmail.com/@/joe
The syntax you suggest is the sort of thing that makes normal, non-technical users break out into a cold sweat -- Yet we want normal folk to be able to use WebFinger... Your proposed syntax is backwards from what normal folk are used to and includes all sorts of special characters in ways that are unfamiliar. Can you explain how the benefits that come from this syntax are great enough to overcome the costs of exposing people to such a radically different and new syntax?
Analysis
=========
Pros: simplicity, remove need for acct:
Cons: involves changing the spec, developer tools, less flexibility of path
I must admit the last point is a biggie ... so I'm just throwing this out there, im undecided in my mind whether this will fly.
Given that much of the webfinger support is still a work in progress, would it be worth considering weighing the pros and cons based on from what we've learnt?
Paul E. Jones
Melvin,
Have you seen this draft?
http://tools.ietf.org/html/draft-jones-appsawg-webfinger
There is still work to do, but things like JSON are a requirement in this new draft. We’re trying to define the acct: URI type in this draft. It should be clearer as we progress the document.
I have no idea what benefit there is in using something like gmail.com/@/joe. That just seems backwards and does not solve the issue you’re describing where there is confusion between the various URI types. A URI is just a URI. Users should generally not have to know or understand a URI type. Nobody enters “mailto:” into their email client. It’s just an address. Likewise, software “behind the scenes” should use “acct:” as appropriate.
Paul
Melvin Carvalho
Yes this looks good, but let's compare flows:
Current webfinger
1. Convert email address to the acct: URI scheme
2. Splice acct: URI to work out the host-meta location
3. Content negotiation on host meta to get XRD or JRD
4. Parse either XRD or JRD to get the LRDD template
5. Use the LRDD template to get location of 'webfinger doc'
6. Content negotiation on webfinger doc to get user data
7. Parse either XRD or JRD to get user information
Proposed simplification:
1. Splice email address to work out webfinger doc
2. Parse JSON to get user information
The other advantage is that there's no need for acct: afaict
/ Pelle
Melvin Carvalho
Melvin,
Have you seen this draft?
http://tools.ietf.org/html/draft-jones-appsawg-webfinger
There is still work to do, but things like JSON are a requirement in this new draft. We’re trying to define the acct: URI type in this draft. It should be clearer as we progress the document.
I have no idea what benefit there is in using something like gmail.com/@/joe. That just seems backwards and does not solve the issue you’re describing where there is confusion between the various URI types. A URI is just a URI. Users should generally not have to know or understand a URI type. Nobody enters “mailto:” into their email client. It’s just an address. Likewise, software “behind the scenes” should use “acct:” as appropriate.
Thanks Paul, imho, great to see that the latest draft has moved to JSON!
The second part is regarding the creation of the acct: scheme. Has there any pushback from IETF / IANA?
From a user perspective the scheme will normally be hidden, but the actual scheme is relevant to architects and standards people.
I am wondering the motivation behind acct:, or if it is still needed at all?
Peter Saint-Andre
> The second part is regarding the creation of the acct: scheme. Has
> there any pushback from IETF / IANA?
First, it's not the IANA's place to push back on the creation of URI
schemes; they're just a registrar.
Second, as to pushback from the IETF, please understand that "the IETF"
is just a convenient shorthand for "the individuals who actively
participate on IETF mailing lists or perhaps show up at IETF meetings".
You too can be part of the IETF if you sign up for a mailing list. :)
The webfinger draft that Paul is working on has been discussed on the
apps-discuss list:
https://www.ietf.org/mailman/listinfo/apps-discuss
See for instance this message from Paul, which includes a bunch of
earlier messages in that thread:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03970.html
Peter
--
Peter Saint-Andre
https://stpeter.im/
Paul E. Jones
I believe people see value in the “acct” scheme. We need something, after all, to identify a user. A person’s profile at Google or Facebook or anywhere else, for example, is not (necessarily) and email address. Webfinger identifiers likely will be of the same form as an email ID since that’s what users will enter. The use of “acct:” should be behind the scenes, IMO. However, it should be valid for a user to enter acct:pau...@packetizer.com if they wanted. It my case, that is also my email ID. It likely would be for most, but we should not build a system that requires an email ID.
There are some who view email as obsolete and unnecessary. They might use services like Twitter or perhaps even a distributed microblogging protocol (that I’ve never seen defined anywhere, but would be cool) where communication between users shifts from email to short messages delivered publicly or privately though this distributed microblogging system, effectively replacing email. In that case, one would need an account identifier that is not an email scheme.
In short, I think there is value in having acct:. It does not have to be something we push to users. We can assume that user@domain is acct:user@domain without the user having to know or care.
Kingsley Idehen
I believe people see value in the “acct” scheme. We need something, after all, to identify a user. A person’s profile at Google or Facebook or anywhere else, for example, is not (necessarily) and email address.
An entity of type: someSchema.Person can be unambiguously identified via a mailto: scheme URI. This identifier will effectively serve the purpose of constructing a description oriented graph for data held in Google, Facebook, or any other data space that's plugged into the Internet.
Webfinger identifiers likely will be of the same form as an email ID since that’s what users will enter. The use of “acct:” should be behind the scenes, IMO.
It my case, that is also my email ID. It likely would be for most, but we should not build a system that requires an email ID.
There are some who view email as obsolete and unnecessary. They might use services like Twitter or perhaps even a distributed microblogging protocol (that I’ve never seen defined anywhere, but would be cool) where communication between users shifts from email to short messages delivered publicly or privately though this distributed microblogging system, effectively replacing email. In that case, one would need an account identifier that is not an email scheme.
In short, I think there is value in having acct:. It does not have to be something we push to users. We can assume that user@domain is acct:user@domain without the user having to know or care.
Kingsley
-- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Melvin Carvalho
I believe people see value in the “acct” scheme. We need something, after all, to identify a user. A person’s profile at Google or Facebook or anywhere else, for example, is not (necessarily) and email address. Webfinger identifiers likely will be of the same form as an email ID since that’s what users will enter. The use of “acct:” should be behind the scenes, IMO. However, it should be valid for a user to enter acct:pau...@packetizer.com if they wanted. It my case, that is also my email ID. It likely would be for most, but we should not build a system that requires an email ID.
There are some who view email as obsolete and unnecessary. They might use services like Twitter or perhaps even a distributed microblogging protocol (that I’ve never seen defined anywhere, but would be cool) where communication between users shifts from email to short messages delivered publicly or privately though this distributed microblogging system, effectively replacing email. In that case, one would need an account identifier that is not an email scheme.
In short, I think there is value in having acct:. It does not have to be something we push to users. We can assume that user@domain is acct:user@domain without the user having to know or care.
Thanks for the response. There were a number of points made, and I agree with almost everything you have to say. I'd like to expand on one point though.
Is there an absolute need, to identify the user explicitly? And, if so, do we need to create a new URI scheme to do that (acct:)
I can think of around five JSON serializations that give you more information from an email address, JRD, JSON-LD, Facebook Open Graph, Simple Web Discovery, BrowserID
Most can do something (roughly) like:
{
email: "mailto:pau...@packetizer.com",
blog: "http://paulej.wordpress.com",
name : "Paul Jones"
}
In this case, where is the need for acct:. I'm not so familiar with exact JRD serialization, is that where the explicit need for a subject comes in?
Kingsley Idehen
> }
>
> In this case, where is the need for acct:. I'm not so familiar with
> exact JRD serialization, is that where the explicit need for a subject
> comes in?
hypermedia based graph e.g., a Linked Data based HTML page. In this
scenario, clicking on the mailto: scheme URI will (more often than not)
trigger you local email client instead of resolving to a description of
the mailto: URI's referent.
That's it :-)
--
Regards,
Kingsley Idehen
Founder& CEO
elf Pavlik
> On 2/29/12 8:37 AM, Melvin Carvalho wrote:
> > }
> >
> > In this case, where is the need for acct:. I'm not so familiar with
> > exact JRD serialization, is that where the explicit need for a subject
> > comes in?
> Ultimately only useful when it comes to follow-your-nose patterns via a
> hypermedia based graph e.g., a Linked Data based HTML page. In this
> scenario, clicking on the mailto: scheme URI will (more often than not)
> trigger you local email client instead of resolving to a description of
> the mailto: URI's referent.
>
> That's it :-)
What about situation when I want to identify myself with joh...@example.net but don't want to have enabled email service for it? Using mailto:joh...@example.net seams little confusing for me in such case...
Someone have told me while ago of finding webfinger 'spammable', obviously not paying attention that webfinger identifier doesn't require enabling email service for it =)
Paul E. Jones
Melvin,
It is acct:pau...@packetizer.com that would be the key used by the webfinger server when returning that JSON you show below.
Bob Wyman
Kingsley Idehen
> Excerpts from Kingsley Idehen's message of 2012-02-29 13:50:25 +0000:
>> On 2/29/12 8:37 AM, Melvin Carvalho wrote:
>>> }
>>>
>>> In this case, where is the need for acct:. I'm not so familiar with
>>> exact JRD serialization, is that where the explicit need for a subject
>>> comes in?
>> Ultimately only useful when it comes to follow-your-nose patterns via a
>> hypermedia based graph e.g., a Linked Data based HTML page. In this
>> scenario, clicking on the mailto: scheme URI will (more often than not)
>> trigger you local email client instead of resolving to a description of
>> the mailto: URI's referent.
>>
>> That's it :-)
> What about situation when I want to identify myself with joh...@example.net but don't want to have enabled email service for it? Using mailto:joh...@example.net seams little confusing for me in such case...
Yes, that's the point I am making re. basis for acct: scheme URI. Such a
case is exemplified by Linked Data graph traversal using
follow-your-nose pattern . In this case, you don't want the email client
to be triggered.
>
> Someone have told me while ago of finding webfinger 'spammable', obviously not paying attention that webfinger identifier doesn't require enabling email service for it =)
Spam is a function of folks not leveraging critical aspects of the Web
and Internet properly (e.g., PKI and S/MIME). If you sign emails and
combine that with protocols such as WebID the ecosystem for spam gets
inverted. By 'inverted' I mean, the burden shifts from end-users to
spammers. They have to figure out how to make fake identifiers that
actually verify against a Web of Trust, and by that I don't mean one
that depends on broken Certificate CA networks.
acct: scheme URIs enable the use of an Identifier that leverages the
intuitiveness of email addresses as personal identifiers without
compromising the virtues of profile oriented Linked Data graphs,
functioning at InterWeb scales. In a nutshell, you end up with a win-win
scenario :-)
Peter Saint-Andre
> The local-name@global-name identifier pattern is too useful, too widely
> understood, too easy to use, for it to be reserved to mail and XMPP
> usage alone. This pattern is the one that normal people will intuitively
> believe is what an identifier *should* look like. It would be a
> disservice to force billions of people to learn a new identifier syntax
> without some truly compelling reason.
I agree with all that.
Your mention of email and XMPP, and of billions of people, leads me to
two concerns:
1. Various identifiers (email, SIP, XMPP) that follow this pattern
differ in the details. See for instance Section 3 of this old I-D:
http://tools.ietf.org/id/draft-saintandre-sip-xmpp-core-01.txt
2. Internationalization. If billions of people will use Webfinger and
related technologies, we need to assume that they won't all have ASCII
account names or traditional domain names.
Gonzalo Salgueiro
On 2/29/12 9:20 AM, Bob Wyman wrote:The local-name@global-name identifier pattern is too useful, too widelyunderstood, too easy to use, for it to be reserved to mail and XMPPusage alone. This pattern is the one that normal people will intuitivelybelieve is what an identifier *should* look like. It would be adisservice to force billions of people to learn a new identifier syntaxwithout some truly compelling reason.
I agree with all that.
Your mention of email and XMPP, and of billions of people, leads me to
two concerns:
1. Various identifiers (email, SIP, XMPP) that follow this pattern
differ in the details. See for instance Section 3 of this old I-D:
http://tools.ietf.org/id/draft-saintandre-sip-xmpp-core-01.txt
2. Internationalization. If billions of people will use Webfinger and
related technologies, we need to assume that they won't all have ASCII
account names or traditional domain names.
Peter Saint-Andre
>
> On Feb 29, 2012, at 11:41 AM, Peter Saint-Andre wrote:
>
>> On 2/29/12 9:20 AM, Bob Wyman wrote:
>>
>>> The local-name@global-name identifier pattern is too useful, too widely
>>> understood, too easy to use, for it to be reserved to mail and XMPP
>>> usage alone. This pattern is the one that normal people will intuitively
>>> believe is what an identifier *should* look like. It would be a
>>> disservice to force billions of people to learn a new identifier syntax
>>> without some truly compelling reason.
>>
>> I agree with all that.
>>
>> Your mention of email and XMPP, and of billions of people, leads me to
>> two concerns:
>>
>> 1. Various identifiers (email, SIP, XMPP) that follow this pattern
>> differ in the details. See for instance Section 3 of this old I-D:
>>
>> http://tools.ietf.org/id/draft-saintandre-sip-xmpp-core-01.txt
>>
>
> This proliferation of identifiers is a problem but not one that I think
> we can easily solve in the context of Webfinger.
I think the acct: URI scheme would simply need to be liberal enough that
the left-hand side of the identifier could include all of the characters
allowed by SIP, email, XMPP, etc.
>> 2. Internationalization. If billions of people will use Webfinger and
>> related technologies, we need to assume that they won't all have ASCII
>> account names or traditional domain names.
>
> This is a recognized shortcoming of the current draft that we plan to
> address in the next version.
Let me know if you'd like assistance with that tricky task.
Gonzalo Salgueiro
On 2/29/12 10:01 AM, Gonzalo Salgueiro wrote:On Feb 29, 2012, at 11:41 AM, Peter Saint-Andre wrote:On 2/29/12 9:20 AM, Bob Wyman wrote:The local-name@global-name identifier pattern is too useful, too widelyunderstood, too easy to use, for it to be reserved to mail and XMPPusage alone. This pattern is the one that normal people will intuitivelybelieve is what an identifier *should* look like. It would be adisservice to force billions of people to learn a new identifier syntaxwithout some truly compelling reason.I agree with all that.Your mention of email and XMPP, and of billions of people, leads me totwo concerns:1. Various identifiers (email, SIP, XMPP) that follow this patterndiffer in the details. See for instance Section 3 of this old I-D:http://tools.ietf.org/id/draft-saintandre-sip-xmpp-core-01.txtThis proliferation of identifiers is a problem but not one that I thinkwe can easily solve in the context of Webfinger.
I think the acct: URI scheme would simply need to be liberal enough that
the left-hand side of the identifier could include all of the characters
allowed by SIP, email, XMPP, etc.
2. Internationalization. If billions of people will use Webfinger andrelated technologies, we need to assume that they won't all have ASCIIaccount names or traditional domain names.This is a recognized shortcoming of the current draft that we plan toaddress in the next version.
Let me know if you'd like assistance with that tricky task.
Melvin Carvalho
Melvin,
It is acct:pau...@packetizer.com that would be the key used by the webfinger server when returning that JSON you show below.
But havent facebook solved this problem giving the best of both worlds. You can login with your email address. You can have a profile or graph or JSON without needing acct:
As an app developer having to deal with acct: vs mailto: identifiers is *really* confusing. Also if acct: is going to be the primary key of of your web based digital footprint, sometimes, and mailto: is sometimes, it's going to lead to a split world, that is tricky to join back together.
My suggestion is just one way to handle things without acct:. But it's not the only way. Facebook do it fine. Amazon and Ebay have done it fine for quite a while. Is there really a compelling need to reinvent here?
I cant help but feel that the cost of splitting the email identifier world, into these 2 schemes is going to be greater, than the overall benefit.
Brad Fitzpatrick
On 29 February 2012 16:56, Paul E. Jones <pau...@packetizer.com> wrote:Melvin,
It is acct:pau...@packetizer.com that would be the key used by the webfinger server when returning that JSON you show below.
But havent facebook solved this problem giving the best of both worlds. You can login with your email address. You can have a profile or graph or JSON without needing acct:
As an app developer having to deal with acct: vs mailto: identifiers is *really* confusing. Also if acct: is going to be the primary key of of your web based digital footprint, sometimes, and mailto: is sometimes, it's going to lead to a split world, that is tricky to join back together.
My suggestion is just one way to handle things without acct:. But it's not the only way. Facebook do it fine. Amazon and Ebay have done it fine for quite a while. Is there really a compelling need to reinvent here?
I cant help but feel that the cost of splitting the email identifier world, into these 2 schemes is going to be greater, than the overall benefit.
Kingsley Idehen
On 29 February 2012 16:56, Paul E. Jones <pau...@packetizer.com> wrote:
Melvin,
It is acct:pau...@packetizer.com that would be the key used by the webfinger server when returning that JSON you show below.
But havent facebook solved this problem giving the best of both worlds. You can login with your email address. You can have a profile or graph or JSON without needing acct:
As an app developer having to deal with acct: vs mailto: identifiers is *really* confusing. Also if acct: is going to be the primary key of of your web based digital footprint, sometimes, and mailto: is sometimes, it's going to lead to a split world, that is tricky to join back together.
My suggestion is just one way to handle things without acct:. But it's not the only way. Facebook do it fine. Amazon and Ebay have done it fine for quite a while. Is there really a compelling need to reinvent here?
I cant help but feel that the cost of splitting the email identifier world, into these 2 schemes is going to be greater, than the overall benefit.
An acct: scheme URI looks like an Email Address but doesn't trigger Email application expectations.
The same analogy applies to http: scheme URIs and Linked Data. The world is familiar with URLs (resource locators/addresses), but for Linked Data abstraction to work, those Web addresses have to play the role of generic Names. Trouble is, although this works magnificently well, it is utterly unintuitive to most.
A de-referencable personal identifier that looks like an Email Address while unleashing the power of indirection, intuitively, is basically the mercurial nirvana we all seek re. portable profile graphs that work at InterWeb scales :-)
Kingsley
-- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com
Gonzalo Salgueiro
Blaine Cook
>
> Yes this looks good, but let's compare flows:
>
> Current webfinger
>
> 1. Convert email address to the acct: URI scheme
> 2. Splice acct: URI to work out the host-meta location
>
> 3. Content negotiation on host meta to get XRD or JRD
> 4. Parse either XRD or JRD to get the LRDD template
>
> 5. Use the LRDD template to get location of 'webfinger doc'
> 6. Content negotiation on webfinger doc to get user data
> 7. Parse either XRD or JRD to get user information
>
> Proposed simplification:
>
> 1. Splice email address to work out webfinger doc
> 2. Parse JSON to get user information
>
> The other advantage is that there's no need for acct: afaict
I've been trying to avoid email as much as possible, but in addition
to giving a +1 to Brad's comments, I wanted to address this straw-man
characterisation of the request flows.
First of all, the proposed simplification is effectively the same as
SWD. From the face of it, it's simpler, but, consider that many
domains that are being asked to provide webfinger support do not have
the ability to run CGI scripts, nor host frequently updating profile
information.
So, the simplification from a provider's perspective is:
1. Decide to support webfinger.
2. Figure out who in the organisation runs the web server.
3. Ask them to add a CGI to /@/$username.
4. Argue with them that it's really important.
5. Find out that the Apache 1.3 server that they're running doesn't
support PHP 5, and therefore can't run ProfileServer2000.
6. Look for a different profile server.
7. Find one that works, but it sucks and isn't maintained.
8. Use it anyways.
9. Get hacked.
10. Repair all the profile data.
11. Go through a security audit.
12. Re-build the web server.
13. Repeat 8-12 as with poorly maintained WordPress installs.
The alternative is to use host-meta, which points to a 3rd party
profile provider (or a local one, if you prefer, or a profile server
maintained by your organisation, but at a different domain than the
primary website).
It's absolutely a trade-off for client developers, but it's important
to consider the deployment scenarios. Client libraries can hide the
complexity, but server-side deployments of a spec that requires a CGI
can't possibly hide the complexity.
b.
Bob Wyman
On 29 February 2012 16:56, Paul E. Jones <pau...@packetizer.com> wrote:Melvin,
It is acct:pau...@packetizer.com that would be the key used by the webfinger server when returning that JSON you show below.
But havent facebook solved this problem giving the best of both worlds. You can login with your email address.
Peter Saint-Andre
>>> I think the acct: URI scheme would simply need to be liberal enough that
>>> the left-hand side of the identifier could include all of the characters
>>> allowed by SIP, email, XMPP, etc.
>
>> Sounds reasonable.
>
>>> 2. Internationalization. If billions of people will use Webfinger and
> related technologies, we need to assume that they won't all have ASCII
> account names or traditional domain names.
>
>> This is a recognized shortcoming of the current draft that we plan to
> address in the next version.
>
>
Sure, that's what part of what makes this work so fun. ;-)
Blaine Cook
>
> Is it really your "email address"? Or, is it just a "unique identifier known
> to be associated with you"? As far as I can see, there is nothing special
> about email addresses in this context. Email addresses are simply one of a
> number of apparently unique strings that Facebook could use. Facebook could
> just as easily allow you to "log in using the phone number in your profile"
> as long as it enforced a rule saying that no two accounts could use the same
> phone number. (That might be difficult...)
> In other words, the Facebook behavior you describe can be generalized to
> something like: "You can log in using any identifier known to be uniquely
> associated with you as long as you also provide the password which is
> registered for you." An acct: identifier would be no different from any
> other identifier which is linked uniquely to a single person (or group).
It actually is your email address, because the reason that Facebook
uses that as your token is so that they can send you a reset token if
you forget your password. In that sense, your ability to verify that
you own your email address is actually a more trusted metric than your
password.
b.