Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[Pelle Wessman <[e-mail]>]

While WebFinger officially requires an "acct" URI I believe almost all current implementers accept a "[e-mail]" URI as being the same as "acct:[e-mail]". Gmail.com does, StatusNet/Identi.ca does, we at Flattr does. So there is a discrepancy between the WebFinger specification and real life implementations.

Examples:

http://www.google.com/s2/webfinger/?q=[e-mail]
http://identi.ca/main/xrd?uri=[e-mail]
https://flattr.com/xrd/lrdd?uri=[e-mail]

Also, speaking from a Flattr-perspective, mail addresses and user accounts are _not_ the same thing in our system. I myself have the e-mail [e-mail] but I have the web site account [e-mail] and the web site account [e-mail] doesn't belong to me but to one of our users. I believe most web sites, at least the smaller ones, works like this - that the e-mail system and the web system is completely separated from each other and that the user identifiers in one can conflict with the identifiers in the other.

I would say that a lookup for "mailto:[e-mail]" should return info about the user behind that e-mail address (if it should return anything) but that a lookup for "[e-mail]" or "acct:[e-mail]" should always return data about the web site user and that clients should be encouraged to use "acct:" to make it clear that they want the web site's user, but that they shouldn't be required to do so.

/ Pelle


19 apr 2012 kl. 00:03 skrev Paul E. Jones:

> Melvin,
>  
> WebFinger does discovery on any URI.  It might be “http”, “mailto”, “ftp”, or “acct”.  So, it’s not entirely correct to say that WebFinger does not do discovery using email addresses.  I could change my server code pretty easily to accommodate mailto.
>  
> Use of mailto was something discussed at length.  As others pointed out, it was not necessarily favored by all, but it was recognized to be insufficient for some situations.  Most importantly, nobody other than us geeks knows what the heck a “mailto” is.  But, we do recognize that social sites like Twitter have accounts.  Thus, after the lengthy debate that took place in several places, it was decided to go with “acct”.  It actually does have a useful purpose.  And its construction is made to look similar to “mailto” so that the a user would just enter what they consider to be an “email” address, including things we know are not like [e-mail].  Using “mailto” is technically incorrect, but users never have to know or care about that.  Behind the scenes, we use “acct”.  I would personally never show an end user “acct:[e-mail]”.  Rather, I would just tell people that their account ID is “[e-mail]”.  That may or may not be their address.  Query a Twitter account and it might return an email address that differs (if Twitter were to share that info).
>  
> Paul
>  
> From: Melvin Carvalho [mailto:[e-mail]] 
> Sent: Wednesday, April 18, 2012 6:05 AM
> To: Paul E. Jones
> Cc: Mike Jones; Apps Discuss
> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
>  
>  
> 
> On 18 April 2012 01:59, Paul E. Jones <[e-mail]> wrote:
> Melvin,
>  
> On “acct:”…
>  
> Humans will usually interchange an acct URI and mailto URI, probably never using either scheme directly in practice.  That’s natural and expected, if not desired.  The intent is that we define something that looks like an email ID, but it’s not an email ID.  Some services, perhaps Twitter being most notable, do no use email addresses.  Yet, you might have an account there.  So, [e-mail] might be used by humans and automated systems would convert that to acct:[e-mail].  It would not be appropriate to use mailto: since it’s not an email ID.
>  
> We did have a lot of debate about the use of “acct”.  If you query my WebFinger server, you’ll see that it will work without “acct:” prefixed, as that was a suggestion made a year or so ago.  It will inspect the input and if it looks like an acct URI, it will assume it is.  The “acct” URI will be returned as an alias.  However, we should always use some kind of URI scheme to remove the guesswork.  The client can often make a very good guess as to whether it’s looking for a user account or something else.  So, let it tell the server what it is looking for explicitly.
>  
> We need a URI scheme, because WebFinger can be used to discover all kinds of information related to a given domain, not only user information.  It can be used to query information about any URI, be that a web page, a user account, device on the network, etc.  If we got rid of “acct”, then we would have a system where we sometimes use a URI scheme and sometimes we do not.  Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence of a scheme defaults to “acct:”.  However, I see no reason for the client to be so lazy to not include “acct:”.  The user might (and probably will) exclude it, but the client code can add it.
>  
> At this point, I’d argue the “train has left the station” on “acct”, too.  The current WebFinger spec exists (in part) to formally document that which has adopted; it’s not a new thing.
> 
> 
> Paul, thank you for your explanation on lookup based on acct: (WebFinger) vs lookup based on mailto: (SWD).
> 
> I think this is a major difference.
> 
> The original WebFinger proposal was *supposed* to give extra information about an email address.
> 
> From wikipedia:
> 
> "WebFinger is an Internet protocol that aims to provide information about people by their E-mail addresses."
> 
> From webfinger.org:
> 
> "Put your email address into the box above, click the button"
> 
> From google code (the top hit on google):
> 
> "making email addresses readable again"
> 
> And perhaps most importantly from the spec, the first example:
> 
> "Assume you receive an email from Bob..."
> 
> However only SWD here is doing email based discovery (mailto:).  WebFinger *now* doing acct: based discovery, which is a departure from the original use case.  
> 
> Im glad that some people have voiced support for acct:, but I still believe that to be a minority.  I agree, that the new acct: scheme should for in another document, rather than shoe horned into an email based discovery system.  
> 
> IMHO, it's better to solve one problem (ie email based discovery) simply and well, than to half solve two problems (ie a new uri scheme for identity) in a single attempt.  
>  
>  
> Paul
>  
> A couple of points:
> 
> 1. JSON
> =======
> 
> I think at the time webfinger was created in 2009, XML was the de facto serialization, used in AJAX, SOAP and many other systems.  Today I'm hearing more and more, that both developers and publishers, want to work with JSON, rather than, having to support both xml and json.  Content negotiation also confuses some publishers.  In my view, this is a great simplification that webfinger can learn from SWD.
> 
> 2. acct: scheme
> =============
> 
> The acct: URI scheme has not proved popular, imho, and has added a layer of complexity and confusion.  How do we get from acct: to mailto:?  When should you use acct: and when mailto: (the spec says acct:user@host may be different from mailto:user@host).  What about the forms.  How about linked data ecosystems that want to cross link identifiers, do they now have to consider both cases?  
> 
> From the original post introducing acct:
> 
> "I don’t expect everyone to like this idea. I wish I could say I love it, but I am simply content with it."
> 
> I dont know of anyone in the community (and correct me if this has changed) that really loves acct:, or perhaps even likes the acct: idea.  SWD has shown you can do discovery without acct: and I think that's a big plus.
> 
> 
> 
> 
> One final side note is that this almost becomes trivial when you can do SPARQL queries.  "void" is already registered by the W3C with IANA in .well-known in order to discover SPARQL endpoints.  It may be overkill in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot bigger than they were in 2009.  In a few years it may become the definitive discovery mechanism anyway.
>  
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss