Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Jun 2013 16:19:58 -0600

On 5/29/13 5:40 PM, Paul E. Jones wrote:
> Peter,
> 
>> I *think* there's still an open issue of how to handle localparts that
>> are of the form user@host (e.g., services that use an email address for
>> registration). So if I register with foo.com with my [email-masked]
>> address and foo.com thinks [email-masked] is the localpart of my acct
>> URI, do we perform the hex-encoding of the '@' character to come up with
>> "acct:[email-masked]"? At the leads, do we make any sort of
>> recommendation about this in the WF spec or do we leave it totally up to
>> implementations? And does it warrant a sentence in the acct-uri spec?
> 
> If you register with foo.com using your email address, that does not
> automatically mean foo.com is going to use that identifier in any way for
> WebFinger.  If I have a blog where you register with [email-masked], my
> server might issue a WF query to example.com to get your picture, name, or
> other information for display on the blog when you post comments, for
> example.
> 
> So, I suppose the question arises when a user on the Internet wants to query
> information about you at your foo.com account.  The way it ought to work is
> that foo.com assign an account identifier for you.  So, you might be
> acct:[email-masked].  Then querying becomes quite natural.  Foo.com is not
> obliged to even run a WF server, too.
> 
> Now, should foo.com decide it does not want to assign account identifiers
> that people can use, yet they still want people to be able to query
> information about users at the service, then it gets complicated.  I would
> not dare suggest to the average user to type in
> acct:[email-masked].  Rather, if foo.com wants to provide a WF
> service and it uses acct:[email-masked] as the account ID, then some
> system that knows and understands that would issue a query to foo.com using
> the resource identifier acct:[email-masked].
> 
> Just to carry this a bit further, just imagine if someone signs up at
> bar.com with their foo.com account.  Then we could have %-encoded %-encoded
> stuff.  This gets really messy.  If a service wants to allow for use of WF
> against the service, they should assign the user an account ID that is
> different from whatever account ID that might have used to create the
> account.  Or, just resign to the fact that the interface will require that
> the peer know and understand that the identifiers presented will not
> necessarily be foo.com identifiers.  There are cases where this might be
> valid and useful, but we do not have to describe such uses in the standard.
> 
> At least that's my view.  I'd rather not make this complicated and this can
> really get messy.

You're right. I'm on board with what you say here. So the question is,
do we need any text here or just leave this up to service providers and
application developers? I tend toward the latter.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 5 Jun 2013 18:26:05 -0400

Paul,

> application developers? I tend toward the latter.

That's my preference, too.  Otherwise, I feel like we're trying to solve a
problem that really wasn't in scope for WF in the first place and, while it
might be useful, we need time to see how this might be used in practice.  We
need to keep the spec simple and let implementers be creative if they want.

Paul