Subject: [apps-discuss] draft-ietf-appsawg-webfinger-04

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 21 Nov 2012 23:13:56 -0500

Folks,

I just posted a new draft that takes into consideration the input I received
on -03 and adds the "webfinger" subdomain that was discussed on the list
this past week.  Specifically, here's what changed:

.         Mention in section 2 that WebFinger uses the "rel" attribute and
provide a reference to the IANA registry for link relations

.         Deleted the second paragraph from  section 3 that expands on link
relations

.         Changed the link relation value for "blog" to be just the token
"blog"

.         Corrected a syntax error in the example in 4.1

.         Clarified in section 4.1 what is meant by a "valid alias"

.         Introduced a new section 4.2 that shows an example for OpenID
Connect

.         Changed the rel types in 4.3 and 4.4 to be URI-based (on
example.net)

.         Corrected syntax in 5.3 and added two clarifying sentences

.         Introduced a new section 5.5 that describes the "webfinger"
subdomain

.         Changed the name of section 7

.         Added language to section 8 to support section 5.5

.         Added language to section 9 to support section 5.5

.         Spells out Mike's name as he prefers it

.         Added a couple of informational references

The new draft is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04

I think we're getting closer, though I know the "webfinger" subdomain might
be a bit controversial.  I'm on the fence on this one, myself.  I can see
the pros and cons of having it.  I'd prefer to stay out of the debate,
though.  I'll put into the document whatever the group says to put into the
documents :-)  That said, I think Mike made a valid argument with respect to
the fact that some domain owners have no ability to do anything more than
insert an A record for a subdomain.

I do want to highlight the fact that the current language says that if there
is any response from a web server at the host, that means the host does have
the capability of providing WF services and the "webfinger" subdomain should
not be consulted.  Thus, the webfinger subdomain would only be consulted if
there is no web server running at the host at all.  It's not a fallback for
domain owners who have a web server, but just didn't install a WF server.
For that case, they should use 3xx redirection for hosting the WF server
elsewhere.

Paul

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 21 Nov 2012 20:26:42 -0800

The new TOC doesn't even have a section 5.5.  Is that how you hide
controversial stuff?  :-)

FWIW, I'm strongly opposed to the subdomain.  It adds complexity.  If you
can't get your load balancing & routing act together, you don't get to
play, sorry.

If it's easy for the small guys, and I've seen it be easy for the medium
guys, and multiple big guys have shown that it's possible, who's
complaining?  (rhetorical. I didn't see when this first appeared, and don't
really want to know)

I don't want incompetence and/or internal politics unnecessarily
complicating a spec that is supposed to be simple for clients.

If we all compromise, nobody wins.  Actually I'll go a step further and be
the dick here and say absolutely not.  I'll fight for implementations that
I write (and those of others whom I can influence) to NOT to do the second
HTTP request (or, uh, 4th if you include https to http fallbacks on each
hostname, ugh), rendering the webfinger subdomain very much not 1st tier
and therefore unreliable.  I already know it'll end up as a forgotten wart
in the spec, like HTTP/1.1 trailers or pipelining.

I mean seriously: the DNS, listening & routing aren't rocket science today
and they weren't 10 years ago either.  If you can't even get that right,
what are the odds you can get webfinger right?

This Thanksgiving I am thankful for Paul putting up with all of us.

Happy turkeys,
Brad

On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones <[email-masked]>wrote:

> Folks,****
>
> ** **
>
> I just posted a new draft that takes into consideration the input I
> received on -03 and adds the “webfinger” subdomain that was discussed on
> the list this past week.  Specifically, here’s what changed:****
>
> **·         **Mention in section 2 that WebFinger uses the “rel”
> attribute and provide a reference to the IANA registry for link relations*
> ***
>
> **·         **Deleted the second paragraph from  section 3 that expands
> on link relations****
>
> **·         **Changed the link relation value for “blog” to be just the
> token “blog”****
>
> **·         **Corrected a syntax error in the example in 4.1****
>
> **·         **Clarified in section 4.1 what is meant by a “valid alias”***
> *
>
> **·         **Introduced a new section 4.2 that shows an example for
> OpenID Connect****
>
> **·         **Changed the rel types in 4.3 and 4.4 to be URI-based (on
> example.net)****
>
> **·         **Corrected syntax in 5.3 and added two clarifying sentences**
> **
>
> **·         **Introduced a new section 5.5 that describes the “webfinger”
> subdomain****
>
> **·         **Changed the name of section 7****
>
> **·         **Added language to section 8 to support section 5.5****
>
> **·         **Added language to section 9 to support section 5.5****
>
> **·         **Spells out Mike’s name as he prefers it****
>
> **·         **Added a couple of informational references****
>
> ** **
>
> The new draft is here:****
>
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04****
>
> ** **
>
> I think we’re getting closer, though I know the “webfinger” subdomain
> might be a bit controversial.  I’m on the fence on this one, myself.  I can
> see the pros and cons of having it.  I’d prefer to stay out of the debate,
> though.  I’ll put into the document whatever the group says to put into the
> documents :-)  That said, I think Mike made a valid argument with respect
> to the fact that some domain owners have no ability to do anything more
> than insert an A record for a subdomain.****
>
> ** **
>
> I do want to highlight the fact that the current language says that if
> there is any response from a web server at the host, that means the host
> does have the capability of providing WF services and the “webfinger”
> subdomain should not be consulted.  Thus, the webfinger subdomain would
> only be consulted if there is no web server running at the host at all.
> It’s not a fallback for domain owners who have a web server, but just
> didn’t install a WF server.  For that case, they should use 3xx redirection
> for hosting the WF server elsewhere.****
>
> ** **
>
> Paul****
>
> ** **
>

---

From: Christian Weiske <[email-masked]>
Date: Thu, 22 Nov 2012 08:39:32 +0100

Hello Paul and Brad,

> > **·         **Introduced a new section 5.5 that describes the
> > “webfinger” subdomain****

> FWIW, I'm strongly opposed to the subdomain.  It adds complexity.  If
> you can't get your load balancing & routing act together, you don't
> get to play, sorry.
I am also opposed to the subdomain, although I don't know the
arguments for it. It makes the spec again more complex.

The reasons given in draft 04 are bogus; if there is no web server
running on that domain (and shall not be), the http traffic can be
routed to another server via iptables or whatnot.
Load balancers exist for ages, so that's no reason either.

Could someone point me to the messages that discussed this? I didn't
find any in [email-masked] nor
[email-masked] about that.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-= Geeking around in the name of science since 1982 =-

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 22 Nov 2012 22:52:45 -0500

I have no idea why the TOC did not get updated, but I'm blaming Word for it. It certainly wasn't an attempt to hide anything.

I'm keeping out of the debate on this one. I think Mike believes strongly that it's needed, so I'll let him make the case. I'll document whatever the group wants.

Paul

-------- Original Message --------
From: Brad Fitzpatrick <[email-masked]>
Sent: Wed Nov 21 23:26:42 EST 2012
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

Happy turkeys,
Brad

> for hosting the WF server elsewhere.****

------------------------------------------------------------------------

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Nicholas Shanks <[email-masked]>
Date: Fri, 23 Nov 2012 09:24:02 +0000

> The email client would take note of the "http://packetizer.com/rel/blog" link relation in the above JRD

Needs amending. I also don't see any need for the subdomain.

— Nicholas.

On 22 Nov 2012, at 04:13, "Paul E. Jones" <[email-masked]> wrote:

> Folks,
>  
> I just posted a new draft that takes into consideration the input I received on -03 and adds the “webfinger” subdomain that was discussed on the list this past week.  Specifically, here’s what changed:
> ·         Mention in section 2 that WebFinger uses the “rel” attribute and provide a reference to the IANA registry for link relations
> ·         Deleted the second paragraph from  section 3 that expands on link relations
> ·         Changed the link relation value for “blog” to be just the token “blog”
> ·         Corrected a syntax error in the example in 4.1
> ·         Clarified in section 4.1 what is meant by a “valid alias”
> ·         Introduced a new section 4.2 that shows an example for OpenID Connect
> ·         Changed the rel types in 4.3 and 4.4 to be URI-based (on example.net)
> ·         Corrected syntax in 5.3 and added two clarifying sentences
> ·         Introduced a new section 5.5 that describes the “webfinger” subdomain
> ·         Changed the name of section 7
> ·         Added language to section 8 to support section 5.5
> ·         Added language to section 9 to support section 5.5
> ·         Spells out Mike’s name as he prefers it
> ·         Added a couple of informational references
>  
> The new draft is here:
> I think we’re getting closer, though I know the “webfinger” subdomain might be a bit controversial.  I’m on the fence on this one, myself.  I can see the pros and cons of having it.  I’d prefer to stay out of the debate, though.  I’ll put into the document whatever the group says to put into the documents :-)  That said, I think Mike made a valid argument with respect to the fact that some domain owners have no ability to do anything more than insert an A record for a subdomain.
>  
> I do want to highlight the fact that the current language says that if there is any response from a web server at the host, that means the host does have the capability of providing WF services and the “webfinger” subdomain should not be consulted.  Thus, the webfinger subdomain would only be consulted if there is no web server running at the host at all.  It’s not a fallback for domain owners who have a web server, but just didn’t install a WF server.  For that case, they should use 3xx redirection for hosting the WF server elsewhere.
>  
> Paul
>

---

From: John Bradley <[email-masked]>
Date: Fri, 23 Nov 2012 14:22:28 +0100

Brad,

In openID Yadis discovery, your employer Google did a back door deal with library authors including JainRain to modify there openID  librays to check with Google to see if a domain is being served by Google apps for domains.  This essentially allows Google to hijack domains not served by Google apps if they were to become evil.

The perhaps even larger problem is that a specific hack for Gooole apps support disenfranchised other potential multi tenant services.

I don't imagine that you are advocating for another google proprietary solution that will be retrofitted into Web Finger.

The functionality to support multi tenant in a standard way has come from Google and some other larger IdP.

I am not saying that the subdomain method (similar provisioning to a apps customer creating mail.mydomain.com as a cname pointing to a hosting provider as is done now.) is the perfect solution.

However a lot of people have been trying to come up with a simple way not to cut off millions of potential users.

If you could ease off on the rhetoric and propose a better way to solve this then people will be more than happy to consider it.

My main concern is to not repeat what I consider to be a serious security problem with openID 2 discovery introduced to support Google Apps.

Regards
John B.

On 2012-11-22, at 5:26 AM, Brad Fitzpatrick <[email-masked]> wrote:

> The new TOC doesn't even have a section 5.5.  Is that how you hide controversial stuff?  :-)
> 
> FWIW, I'm strongly opposed to the subdomain.  It adds complexity.  If you can't get your load balancing & routing act together, you don't get to play, sorry.
> 
> If it's easy for the small guys, and I've seen it be easy for the medium guys, and multiple big guys have shown that it's possible, who's complaining?  (rhetorical. I didn't see when this first appeared, and don't really want to know)
> 
> I don't want incompetence and/or internal politics unnecessarily complicating a spec that is supposed to be simple for clients.
> 
> If we all compromise, nobody wins.  Actually I'll go a step further and be the dick here and say absolutely not.  I'll fight for implementations that I write (and those of others whom I can influence) to NOT to do the second HTTP request (or, uh, 4th if you include https to http fallbacks on each hostname, ugh), rendering the webfinger subdomain very much not 1st tier and therefore unreliable.  I already know it'll end up as a forgotten wart in the spec, like HTTP/1.1 trailers or pipelining.
> 
> I mean seriously: the DNS, listening & routing aren't rocket science today and they weren't 10 years ago either.  If you can't even get that right, what are the odds you can get webfinger right?
> 
> On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones <[email-masked]> wrote:
> Folks,
> 
>  
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Nov 2012 09:52:12 -0500

I corrected that for -05. Thanks!

Paul

-------- Original Message --------
From: Nicholas Shanks <[email-masked]>
Sent: Fri Nov 23 04:24:02 EST 2012
To: "Paul E. Jones" <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>, "<[email-masked]>" <[email-masked]>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

— Nicholas.

---

From: James M Snell <[email-masked]>
Date: Fri, 23 Nov 2012 08:51:35 -0800

At this point, I'd have to say that I'm not entirely convinced that the
subdomain option is useful either but I'd need to get some more direct
implementation experience with this variation of the spec to say for
certain.

The one variation on this that I've been kicking around is the SRV
option... e.g.

 _webfinger._http.example.com. 86400 IN SRV 0 5 80 example.org.

Essentially allowing the example.com to point to example.org as the
location of it's WebFinger services. Obviously there are issues with this
approach as well but I would suspect that it's at least as viable as the
subdomain approach (and arguably more flexible). That said, however, we
could likely keep going around n around on possible viable solutions... at
this point let's all just go write some code for a bit and really see which
approach works best.

- James

On Fri, Nov 23, 2012 at 6:52 AM, Paul E. Jones <[email-masked]>wrote:

> ------------------------------
> *From:* Nicholas Shanks <[email-masked]>
> *Sent:* Fri Nov 23 04:24:02 EST 2012
> *To:* "Paul E. Jones" <[email-masked]>
> *Cc:* "<[email-masked]>" <[email-masked]>, "<
> [email-masked]>" <[email-masked]>
> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-04
>
> the list this past week.  Specifically, here’s what changed:
>
> ·         Mention in section 2 that WebFinger uses the “rel” attribute
> and provide a reference to the IANA registry for link relations
>
> ·         Corrected a syntax error in the ex! ample in 4.1
>
> than insert an A record for a subdomain.
>
>
>
> for hosting the WF server elsewhere.
>
>
>
> Paul
>
>
>

---

From: William Mills <[email-masked]>
Date: Fri, 23 Nov 2012 08:58:24 -0800 (PST)

SRV records have several problems, two are:  they are not widely enough adopted and many hosting providers don't support them, and JS (and other browser based solutions) can't look them up so we'd need new code rolled out in browsers to make them useful.

SRV records are a great solution intellectually, but not practically at this time.

-bill

>________________________________
> From: James M Snell <[email-masked]>
>To: Paul E. Jones <[email-masked]> 
>Cc: Nicholas Shanks <[email-masked]>; "<[email-masked]>" <[email-masked]>; "<[email-masked]>" <[email-masked]> 
>Sent: Friday, November 23, 2012 8:51 AM
>At this point, I'd have to say that I'm not entirely convinced that the subdomain option is useful either but I'd need to get some more direct implementation experience with this variation of the spec to say for certain.
>
>
>The one variation on this that I've been kicking around is the SRV option... e.g.
>
>
>Essentially allowing the example.com to point to example.org as the location of it's WebFinger services. Obviously there are issues with this approach as well but I would suspect that it's at least as viable as the subdomain approach (and arguably more flexible). That said, however, we could likely keep going around n around on possible viable solutions... at this point let's all just go write some code for a bit and really see which approach works best.
>
>
>- James
>
>
>
>On Fri, Nov 23, 2012 at 6:52 AM, Paul E. Jones <[email-masked]> wrote:
>
>>________________________________
>>>I do want to highlight the fact that the current language says that if there is any response from a web server at the host, that means the host does have the capability of providing WF services and the
“webfinger” subdomain should not be consulted.  Thus, the webfinger subdomain would only be consulted if there is no web server running at the host at all.  It’s not a fallback for domain owners who have a web server, but just didn’t install a WF server.  For that case, they should use 3xx redirection for hosting the WF server elsewhere.

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Nov 2012 21:19:53 +0000

Thanks for writing this, John.  It's important for people to understand that this is a real problem - not a theoretical problem - and that the consequences of not solving the problem in a practically implementable standards-based manner could once again be deployment of a vendor-specific solution that locks out other participants.

I'll be the first to say that I don't architecturally love the domain prefix solution.  I described it in http://tools.ietf.org/html/draft-jones-simple-web-discovery-04 and applaud Paul for including it in http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 because it will generate concrete discussion on the best practical solutions to the problem.  If people propose an alternative solution that is implementable on all modern Web development platforms today and usable in all existing web hosting environments that has better properties than the domain prefix solution, I'd be great with that.  But as it is, we have at least one workable solution to the problem.

By modern web development platforms, I would include at least all of JavaScript, Ruby, PHP, Python, node.js, Java, .NET, Windows, OS X, iOS, Android, and Windows Phone.  While people have discussed the limitations of JavaScript with respect to SRV records, any solution needs to work for all these environments (and possibly more).

                                                            Best wishes,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Friday, November 23, 2012 5:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

Brad,

I am not saying that the subdomain method (similar provisioning to a apps customer creating mail.mydomain.com<http://mail.mydomain.com> as a cname pointing to a hosting provider as is done now.) is the perfect solution.

Regards
John B.

On 2012-11-22, at 5:26 AM, Brad Fitzpatrick <[email-masked]<mailto:[email-masked]>> wrote:

Happy turkeys,
Brad

On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

I just posted a new draft that takes into consideration the input I received on -03 and adds the "webfinger" subdomain that was discussed on the list this past week.  Specifically, here's what changed:

*         Mention in section 2 that WebFinger uses the "rel" attribute and provide a reference to the IANA registry for link relations

*         Deleted the second paragraph from  section 3 that expands on link relations

*         Changed the link relation value for "blog" to be just the token "blog"

*         Corrected a syntax error in the example in 4.1

*         Clarified in section 4.1 what is meant by a "valid alias"

*         Introduced a new section 4.2 that shows an example for OpenID Connect

*         Changed the rel types in 4.3 and 4.4 to be URI-based (on example.net<http://example.net/>)

*         Corrected syntax in 5.3 and added two clarifying sentences

*         Introduced a new section 5.5 that describes the "webfinger" subdomain

*         Changed the name of section 7

*         Added language to section 8 to support section 5.5

*         Added language to section 9 to support section 5.5

*         Spells out Mike's name as he prefers it

*         Added a couple of informational references

The new draft is here:

I think we're getting closer, though I know the "webfinger" subdomain might be a bit controversial.  I'm on the fence on this one, myself.  I can see the pros and cons of having it.  I'd prefer to stay out of the debate, though.  I'll put into the document whatever the group says to put into the documents :-)  That said, I think Mike made a valid argument with respect to the fact that some domain owners have no ability to do anything more than insert an A record for a subdomain.

I do want to highlight the fact that the current language says that if there is any response from a web server at the host, that means the host does have the capability of providing WF services and the "webfinger" subdomain should not be consulted.  Thus, the webfinger subdomain would only be consulted if there is no web server running at the host at all.  It's not a fallback for domain owners who have a web server, but just didn't install a WF server.  For that case, they should use 3xx redirection for hosting the WF server elsewhere.

Paul

---

From: Dick Hardt <[email-masked]>
Date: Fri, 23 Nov 2012 14:19:07 -0800

Hi Brad

The problem was not discussed on the list. The relevant part of the SWD document is below

Myself, I would like to be pointed to real world examples as I don't appreciate the issue yet.

-- Dick

2.1.  "simple-web-discovery" Subdomain

   It may be difficult or impossible for some domains wanting to support
   SWD requests to make an SWD server available for their domain at the
   path "/.well-known/simple-web-discovery".  For instance, in the case
   of hosted domains, no web server may be running on the domain host at
   all.

   For that reason, SWD servers for a domain MAY be located on a
   specific subdomain of that domain: "simple-web-discovery".  For
   example, the SWD server for the domain "example.com" MAY be located
   at the URI "https://simple-web-discovery.example.com/.well-known/simp
   le-web-discovery".

Jones & Goland             Expires May 9, 2013                  [Page 4]
 
Internet-Draft         Simple Web Discovery (SWD)          November 2012

   SWD clients MUST first attempt to make an SWD request to the domain's
   "/.well-known/simple-web-discovery" endpoint, and then if that fails,
   they MUST then attempt to make the request to the SWD endpoint at the
   "simple-web-discovery" subdomain for the domain.

On Nov 23, 2012, at 2:09 PM, Brad Fitzpatrick <[email-masked]> wrote:

> On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <[email-masked]> wrote:
> Thanks for writing this, John.  It’s important for people to understand that this is a real problem – not a theoretical problem – and that the consequences of not solving the problem in a practically implementable standards-based manner could once again be deployment of a vendor-specific solution that locks out other participants.
> 
> 
> What's the problem?
> 
> I missed some emails, if there were any about this.  Is there discussion happening on a mailing list other than apps-discuss and/or [email-masked]?
> 
> We already have the /.well-known/ thing, so why do we need a well-known subdomain?
> 
> The way I see it is:
> 
> a) If you're aren't running a webserver on the hostname => run one, and respond to /.well-known/webfinger
> b) If you are running a webserver on the hostname => respond to /.well-known/webfinger
> 
> We need to make things easier for clients, not easier for servers.  There will many more clients than servers, so it needs to be hard to get wrong, if we want people to do the right thing.
> 
> Let's imagine that the "webfinger" subdomain goes into the spec, but no major webfinger server uses it.  So now we have 99% of webfinger client applications (many in JavaScript) only implementing the base case and ignoring the subdomain lookup, because it always works as far as they're concerned.  Now new servers have no choice but to respond at host.com/.well-known/webfinger because most clients won't work otherwise.  That's where I fear this is all heading:  because of a misguided desired to make things easier for some hypothetical server authors, we then make things complicated for everybody, even though we gain nothing.
> 
> When you have more clients than servers, I think it's important to make things simple for clients.
>

---

From: Blaine Cook <[email-masked]>
Date: Fri, 23 Nov 2012 22:39:04 +0000

+1 to this new draft, and +1 to Brad's comments on the draft – I, too,
think the subdomain introduces unnecessary complexity on the client in
deference to seemingly unspecified servers that can't (apparently) run web
servers.

b.

On 23 November 2012 22:31, Brad Fitzpatrick <[email-masked]> wrote:

> Okay, glad I didn't miss anything. Section 2.1 of SWD doesn't explain the
> problem: for some reason, running a webserver "may be difficult or
> impossible", so it pushes complexity to clients instead.
>
>
> On Fri, Nov 23, 2012 at 2:19 PM, Dick Hardt <[email-masked]> wrote:
>
>> Hi Brad
>>
>> 2.1 <http://tools.ietf.org/html/draft-jones-simple-web-discovery-04#section-2.1>.  "simple-web-discovery" Subdomain
>>
>>
>>   <http://tools.ietf.org/html/draft-jones-simple-web-discovery-04#page-5>Internet-Draft         Simple Web Discovery (SWD)          November 2012
>>
>>
>> On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <[email-masked]>wrote:
>>
>>>  Thanks for writing this, John.  It’s important for people to
>>> understand that this is a real problem – not a theoretical problem – and
>>> that the consequences of not solving the problem in a practically
>>> implementable standards-based manner could once again be deployment of a
>>> vendor-specific solution that locks out other participants.
>>>
>>
>> What's the problem?
>>
>> I missed some emails, if there were any about this.  Is there discussion
>> happening on a mailing list other than apps-discuss and/or
>> [email-masked]?
>>
>> We need to make things easier for clients, not easier for servers.  There
>> will many more clients than servers, so it needs to be hard to get wrong,
>> if we want people to do the right thing.
>>
>> Let's imagine that the "webfinger" subdomain goes into the spec, but no
>> major webfinger server uses it.  So now we have 99% of webfinger client
>> applications (many in JavaScript) only implementing the base case and
>> ignoring the subdomain lookup, because it always works as far as they're
>> concerned.  Now new servers have no choice but to respond at
>> host.com/.well-known/webfinger because most clients won't work
>> otherwise.  That's where I fear this is all heading:  because of a
>> misguided desired to make things easier for some hypothetical server
>> authors, we then make things complicated for everybody, even though we gain
>> nothing.
>>

---

From: Tim Bray <[email-masked]>
Date: Fri, 23 Nov 2012 17:34:06 -0800

Notes on draft-ietf-appsawg-webfinger-04.txt

Sorry for coming late to the party. This the first webfinger draft
that I’ve ever read, and I’m almost completely ignorant of the
history.  Having said that, sometimes a history-free pair of eyes
looking at something can add value.

[1. Introduction. ]

Suggest shortening up, omitting the history, losing the whole first
para and beginning the second “Webfinger uses the HTTP protocol to
retrieve a structured document containing link relations that describe
people or other entities on the Internet. For a person...

[para 2]  “direct human consumption (e.g., looking up someone’s phone
number), or...”

[4. Example use of WebFinger] Tighten up 1st sentence: “This section
shows a few sample uses of Webfinger.”

[4.1 Locating a User's Blog]

What is the benefit of the “aliases” field?

What is the benefit of the “acct” URI scheme?  Couldn’t “mailto:” have
been used in this case?

[4.2 Identity Provider Discovery...]

Since the “rel” parameter is optional and you can’t count on it,
providing it is strictly a client-suggested optimization?  Feels quite
likely to be premature, to me.

In particular, I’m thinking of my own small-scale domains like
textuality.com and tbray.org, which have a single-digit number of
accounts.  I could drop static JRD files into a small number of files
with names like
/.well-known/webfinger?resource=mailto:[email-masked] and do
webfinger very cheaply. The existence of the “rel” parameter means I
can’t solve this problem statically.

[4.4 Retrieving Device Information]

I have to say this feels fanciful. Any time an example requires
inventing a new URI scheme, I suggest that’s a symptom of trying too
hard.

[5.1, first para]

I hate to be pedantic, but when you say “parameter”, you’re talking
about the &-separated name-value pairs in the “query” [RFC3986] part
of a URI.  Fine enough, and it’s a common usage, but I don’t actually
know where it's defined (not in 3986) so either we need to find a
definition and link to it, or invest a paragraph in saying what you
mean

[5.1] “WebFinger servers MUST return JRD documents as the default
representation...” What does “default” mean?  Are we saying that
servers MUST return JRD?  If so, say so.

[5.1] Last two paragraphs are perhaps superfluous?  Since it’s HTTP,
don’t you get this for free?

[5.2] “Any array elements within the "links" array are presented by
the server in order of preference.”  Huh? Don't understand.

[5.2] “The "template" element is forbidden“?  Huh?  The spec doesn’t
define any semantic for this element.
You probably need a  policy on unknown fields. For example:
(a) “Software must ignore any fields found in the JRD which are not
specified here” (a.k.a. MUST_IGNORE)
(b) “It is forbidden for any elements not specified here to appear in
a JRD“ (a.k.a. maximally brittle)
The special processing for “template” is just weird.  If it’s required
for some good reason, give the reason.

[5.2] The fact that “titles” is allowed but has no specified semantics
is troublesome.  Explain or remove?
[5.2] The fact there is no discussion of what you might use
“properties” for, nor any discussion of its structure, is troublesome.
 Do we have actual users of this?  Explain or remove?

[5.3] “The purpose of the "rel" parameter is to return a subset of
resource's link relations.  It is not intended to reduce the work”
Could this be motivated a bit?  Why would you want a subset, aside
from reducing the work?

[5.3] The restated example doesn’t really add value here, I think. How
the “rel” parameter works is simple enough.

[5.4] Two problems: First, this section fails to convince me that the
“acct” scheme is worth the effort. Second, the section could simply
say that the URI used to identify the entity being queried is not tied
to any scheme; the arm-waving about the hypothetical wonderfulnesss of
“acct:” is a waste of space.  Then having done that, the section could
be replaced by a one-line note in section 5.1

[5.5] Really?  Do we have any hard data that convinces us that there’s
an interesting class of organizations that (a) want to offer WebFinger
and (b) can’t access their root and (c) can easily set up a subdomain?

[6] “Enterprise”?! What does that word mean?  Also there’s a
contradiction between the sentence saying you have to use “*” and the
next paragraph saying something more restrictive is OK.  Might it be
better to just say “WebFinger may not be usable from code running in
browsers due to Origin policies; therefore, the use of CORS headers is
required. The header “Access-Control-Allow-Origin: * ” will maximize
usability; certain organizations may wish to control access to
WebFinger with a more restrictive Access-Control-Allow-Origin value.

[7. Access Control]

This section could be dropped, or replaced with a short paragraph
noting that since WebFinger is based on HTTP, implementors will need
to deal with the possibility that the origin server may impose access
control policies or simply refuse access.

[8.]  This section could be dropped.  This is an HTTP-based service
and we can assume that implementors should be prepared to handle
HTTP-standard redirect semantics.  The caution about not redirecting
to a /.well-known somewhere else seems of questionable value, since I
might actually want to have a common webfinger which returns the same
values for any X whether it's [email-masked], [email-masked], or
whatever, and I could do that efficiently by having a /.well-known on
one of them and redirecting to it from the others.

On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones <[email-masked]> wrote:
> on -03 and adds the “webfinger” subdomain that was discussed on the list
> this past week.  Specifically, here’s what changed:
>
> ·         Mention in section 2 that WebFinger uses the “rel” attribute and
> I think we’re getting closer, though I know the “webfinger” subdomain might
> be a bit controversial.  I’m on the fence on this one, myself.  I can see
> the pros and cons of having it.  I’d prefer to stay out of the debate,
> the capability of providing WF services and the “webfinger” subdomain should
> there is no web server running at the host at all.  It’s not a fallback for
> domain owners who have a web server, but just didn’t install a WF server.

---

From: Tim Bray <[email-masked]>
Date: Fri, 23 Nov 2012 22:32:47 -0800 (PST)

Oops, I replied to this but hadn’t bothered to join the mailing list first, 
so it bounced.  Here it is again:

Sorry for coming late to the party. This the first webfinger draft that 
I’ve ever read, and I’m almost completely ignorant of the history.  Having 
said that, sometimes a history-free pair of eyes looking at something can 
add value.

[1. Introduction. ]

Suggest shortening up, omitting the history, losing the whole first para 
and beginning the second “Webfinger uses the HTTP protocol to retrieve a 
structured document containing link relations that describe people or other 
entities on the Internet. For a person...

[4. Example use of WebFinger] Tighten up 1st sentence: “This section shows 
a few sample uses of Webfinger.”

[4.1 Locating a User's Blog] What is the benefit of the “aliases” field?

What is the benefit of the “acct” URI scheme?  Couldn’t “mailto:” have been 
used in this case?

Since the “rel” parameter is optional and you can’t count on it, providing 
it is strictly a client-suggested optimization?  Feels quite likely to be 
premature, to me.

In particular, I’m thinking of my own small-scale domains like 
textuality.com and tbray.org, which have a single-digit number of accounts. 
 I could drop static JRD files into a small number of files with names like 
/.well-known/webfinger?resource=mailto:[email-masked] and do 
webfinger very cheaply. The existence of the “rel” parameter means I can’t 
solve this problem statically.

I have to say this feels fanciful. Any time an example requires inventing a 
new URI scheme, I suggest that’s a symptom of trying too hard.

[5.1, first para]

I hate to be pedantic, but when you say “parameter”, you’re talking about 
the &-separated name-value pairs in the “query” [RFC3986] part of a URI. 
 Fine enough, and it’s a common usage, but I don’t actually know where it's 
defined (not in 3986) so either we need to find a definition and link to 
it, or invest a paragraph in saying what you mean

[5.1] “WebFinger servers MUST return JRD documents as the default 
representation...” What does “default” mean?  Are we saying that servers 
MUST return JRD?  If so, say so.

[5.1] Last two paragraphs are perhaps superfluous?  Since it’s HTTP, don’t 
you get this for free?

[5.2] “Any array elements within the "links" array are presented by the 
server in order of preference.”  Huh? Don't understand.

[5.2] “The "template" element is forbidden“?  Huh?  The spec doesn’t define 
any semantic for this element. You probably need a  policy on unknown 
fields. For example:
(a) “Software must ignore any fields found in the JRD which are not 
specified here” (a.k.a. MUST_IGNORE)
(b) “It is forbidden for any elements not specified here to appear in a 
JRD“ (a.k.a. maximally brittle)
The special processing for “template” is just weird.  If it’s required for 
some good reason, give the reason.

[5.2] The fact that “titles” is allowed but has no specified semantics is 
troublesome.  Explain or remove?
[5.2] The fact there is no discussion of what you might use “properties” 
for, nor any discussion of its structure, is troublesome.  Do we have 
actual users of this?  Explain or remove?

[5.3] “The purpose of the "rel" parameter is to return a subset of 
resource's link relations.  It is not intended to reduce the work” Could 
this be motivated a bit?  Why would you want a subset, aside from reducing 
the work?

[5.3] The restated example doesn’t really add value here, I think. How the 
“rel” parameter works is simple enough.

[5.4] Two problems: First, this section fails to convince me that the 
“acct” scheme is worth the effort. Second, the section could simply say 
that the URI used to identify the entity being queried is not tied to any 
scheme; the arm-waving about the hypothetical wonderfulnesss of
“acct:” is a waste of space.  Then having done that, the section could be 
replaced by a one-line note in section 5.1

[5.5] Really?  Do we have any hard data that convinces us that there’s an 
interesting class of organizations that (a) want to offer WebFinger
and (b) can’t access their root and (c) can easily set up a subdomain?

[6] “Enterprise”?! What does that word mean?  Also there’s a contradiction 
between the sentence saying you have to use “*” and the next paragraph 
saying something more restrictive is OK.  Might it be better to just say 
“WebFinger may not be usable from code running in
browsers due to Origin policies; therefore, the use of CORS headers is 
required. The header “Access-Control-Allow-Origin: * ” will maximize
usability; certain organizations may wish to control access to WebFinger 
with a more restrictive Access-Control-Allow-Origin value.

[7. Access Control] This section could be dropped, or replaced with a short 
paragraph noting that since WebFinger is based on HTTP,  implementors will 
need to deal with the possibility that the origin server may impose access 
control policies or simply refuse access.

[8.]  This section could be dropped.  This is an HTTP-based service and we 
can assume that implementors should be prepared to handle
HTTP-standard redirect semantics.  The caution about not redirecting to a 
/.well-known somewhere else seems of questionable value, since I might 
actually want to have a common webfinger which returns the same values for 
any X whether it's [email-masked], [email-masked], or whatever, and I could 
do that efficiently by having a /.well-known on one of them and redirecting 
to it from the others.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 24 Nov 2012 02:13:16 -0500

You can always redirect requests elsewhere, but if we don't have fixed resource locations, it makes discovery a challenge.

Paul

-------- Original Message --------
From: Kingsley Idehen <[email-masked]>
Sent: Fri Nov 23 17:17:24 EST 2012
To: [email-masked]
Cc: Brad Fitzpatrick <[email-masked]>, John Bradley <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/23/12 5:09 PM, Brad Fitzpatrick wrote:
> On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     understand that this is a real problem – not a theoretical problem
>     – and that the consequences of not solving the problem in a
>     practically implementable standards-based manner could once again
>     be deployment of a vendor-specific solution that locks out other
>     participants.
>
>
> What's the problem?
>
> I missed some emails, if there were any about this.  Is there 
> discussion happening on a mailing list other than apps-discuss and/or 
> [email-masked] <mailto:[email-masked]>?
>
> We need to make things easier for clients, not easier for servers. 
>  There will many more clients than servers, so it needs to be hard to 
> get wrong, if we want people to do the right thing.
>
> Let's imagine that the "webfinger" subdomain goes into the spec, but 
> no major webfinger server uses it.  So now we have 99% of webfinger 
> client applications (many in JavaScript) only implementing the base 
> case and ignoring the subdomain lookup, because it always works as far 
> as they're concerned.  Now new servers have no choice but to respond 
> at host.com/.well-known/webfinger 
> <http://host.com/.well-known/webfinger> because most clients won't 
> work otherwise.  That's where I fear this is all heading:  because of 
> a misguided desired to make things easier for some hypothetical server 
> authors, we then make things complicated for everybody, even though we 
> gain nothing.
>

All,

A late in the game request. Is there any chance of 
<host.com/.well-known/{path}/webfinger 
<http://host.com/.well-known/webfinger>> and/or 
<host.com/{path}/.well-known/webfinger 
<http://host.com/.well-known/webfinger>> instead of just 
<host.com/.well-known/webfinger <http://host.com/.well-known/webfinger>> 
or <host.com/.well-known/webfinger 
<http://host.com/.well-known/webfinger>> ?

Goal: to be able to deploy a Webfinger accessible profile document via 
the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, 
Amazon S3 buckets etc.. Basically, removing the HTTP server ownership 
and admin requirement by moving scope to a document path rather than a 
host.

-- 

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

---

From: Brad Fitzpatrick <[email-masked]>
Date: Fri, 23 Nov 2012 14:09:11 -0800

On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <[email-masked]>wrote:

>  Thanks for writing this, John.  It’s important for people to understand
> that this is a real problem – not a theoretical problem – and that the
> consequences of not solving the problem in a practically implementable
> standards-based manner could once again be deployment of a vendor-specific
> solution that locks out other participants.
>

What's the problem?

We already have the /.well-known/ thing, so why do we need a well-known
subdomain?

The way I see it is:

a) If you're aren't running a webserver on the hostname => run one, and
respond to /.well-known/webfinger
b) If you are running a webserver on the hostname => respond to
/.well-known/webfinger

Let's imagine that the "webfinger" subdomain goes into the spec, but no
major webfinger server uses it.  So now we have 99% of webfinger client
applications (many in JavaScript) only implementing the base case and
ignoring the subdomain lookup, because it always works as far as they're
concerned.  Now new servers have no choice but to respond at
host.com/.well-known/webfinger because most clients won't work otherwise.
 That's where I fear this is all heading:  because of a misguided desired
to make things easier for some hypothetical server authors, we then make
things complicated for everybody, even though we gain nothing.

When you have more clients than servers, I think it's important to make
things simple for clients.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Fri, 23 Nov 2012 14:31:24 -0800

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 24 Nov 2012 11:21:31 -0500

I don't understand how this would work. Suppose I write a client that wants to look up information on a given user. Using the well-known location, the client code is fairly simple. If we use different paths, we'd need a discovery mechanism for the path, no?

Paul

-------- Original Message --------
From: Kingsley Idehen <[email-masked]>
Sent: Sat Nov 24 11:05:58 EST 2012
To: [email-masked]
Cc: "Paul E. Jones" <[email-masked]>, Brad Fitzpatrick <[email-masked]>, John Bradley <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/24/12 2:13 AM, Paul E. Jones wrote:
>
> You can always redirect requests elsewhere, but if we don't have fixed 
> resource locations, it makes discovery a challenge.
>
> _Paul_
>
__
Yes, but I am seeking a way to alleviate the following challenges for 
end-users seeking to exploit Webfinger:

1. domain ownership
2. domain name server admin privileges
3. web server admin privileges.

Right now, Webfinger scopes everything to the "host" in a Web realm that 
is really scoped to documents (Web 1.0 and 2.0) and named entities (Web 
3.0 via Linked Data).

Is it too costly to add "paths" to Webfinger bearing in mind the 
granularity this option provides i.e., rather being aimed at service 
providers (who control domain name and web servers) it also serves the 
needs of profile document owners and individuals that seek full control 
over their digital identities.

The upside of this non disruptive tweak is massive.

Kingsley

> *From:* Kingsley Idehen <[email-masked]>
> *Sent:* Fri Nov 23 17:17:24 EST 2012
> *To:* [email-masked]
> *Cc:* Brad Fitzpatrick <[email-masked]>, John Bradley 
> <[email-masked]>, "[email-masked]" <[email-masked]>
>>     understand that this is a real problem – not a theoretical
>>     problem – and that the consequences of not solving the problem in
>>     a practically implementable standards-based manner could once
>>     again be deployment of a vendor-specific solution that locks out
>>     other participants.
>>
>>
>> What's the problem?
>>
>> case and ignoring the subdomain lookup, because it always works as 
>> far as they're concerned.  Now new servers have no choice but to 
>> respond at host.com/.well-known/webfinger 
>> a misguided desired to make things easier for some hypothetical 
>> server authors, we then make things complicated for everybody, even 
>> though we gain nothing.
>>
> <host.com/.well-known/webfinger 
> <http://host.com/.well-known/webfinger>> or 
> <host.com/.well-known/webfinger 
> Company Web:http://www.openlinksw.com
> Personal Weblog:http://www.openlinksw.com/blog/~kidehen
> Google+ Profile:https://plus.google.com/112399767740508618350/about
> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software

---

From: Mikael Nordfeldth <[email-masked]>
Date: Sat, 24 Nov 2012 18:10:13 +0100

>  _webfinger._http.example.com. 86400 IN SRV 0 5 80 example.org.

IIRC Patrik Fältström has been proposing this idea as well and I too 
believe it is a great solution. However arguably not something that can 
be implemented reliably in many DNS clients in use today.
(also, shouldn't it be _webfinger._tcp.example.com. with https/http 
implied for the service type?)

Either way a DNS resolution would solve all issues the subdomain 
attempts to solve and also allow for a lot more flexibility in service 
lookup (such as service port and third-party domain name).

The subdomain solution is suboptimal and anyone who can setup such a 
subdomain on a _redundant_ webserver (vhosting is vulnerable to the same 
routing/hardware issues) would also be able to do proper load balancing 
and other service redundancy for the hostname's /.well-known/webfinger

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
[email-masked]
+46705657637

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 25 Nov 2012 01:23:07 +0100

On 24 nov 2012, at 18:10, Mikael Nordfeldth <[email-masked]> wrote:

> However arguably not something that can be implemented reliably in many DNS clients in use today.

The reason why I rise this over and over again is that YES, I do know that dns hosting providers do not support SRV, and yes, I do know that Java Script and other things do not support SRV.

But, to me I have heard this for so many years (>10) that it seems weird that people still complain about it and say they must do overrides in higher layers in the protocol stack than fix the very very few places where SRV is not supported.

I.e. how many places do SRV support have to be added compared with the number of implementations that have to implement whatever is to implement the work around the lack of support for SRV?

And, regarding for example dns hosting providers, if you want SRV, why do you not search for a dns hosting provider that support SRV instead of "just" using the closest/cheapest/whatever than looking for one that do support SRV? Unless one do not search for one, the market economy forces that drives innovation and our economy as a whole does not work very well.

So, to conclude, yes, I do know SRV is not supported in some key systems out there. And even worse with other newer resource record types.

I am just surprised people do use these "bugs" as arguments still.

I.e. SRV was first specified in RFC 2052, released in october 1996. I mean, for how long time is it ok to claim it is a "new thing" that people have not implemented it, and when will people require it?

1996 is now 16 years go!

I mean, whats the problem?

About time to implement it, or?

   Patrik

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 24 Nov 2012 20:17:54 -0500

> About time to implement it, or?

well, it is implemented and heavily in use for 80% of the tablet market, 33% of smartphone market and 15% of the laptop market.

;-)

Marc.

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2012 01:59:51 -0000

>I.e. how many places do SRV support have to be added compared with the
>number of implementations that have to implement whatever is to
>implement the work around the lack of support for SRV?

In practice, just one, in Javascript.  If there were demand for SRV
records, DNS providers would figure out how to handle them, just like
they did for TXT records when SPF and DKIM became popular.

The problem isn't a technical one, it's a social one.  Even compared
to the rest of the IETF, the DNS crowd has remarkably poor social
skills.  

I think it would be dandy if one could do SRV lookups from Javascript,
since it would make a bunch of other service discovery problems
easier, such as the ones we're looking at in WEIRDS (with arguments
not unlike the ones here.)  But if after 16 years, the people who
maintain Javascript are unpersuaded that would be worth tneir time to
add SRV lookups, it's not because they are stupid.  (We can discuss
all the ways the DNS crowd shoot themselves in the foot somewhere
else.)

>About time to implement it, or?

Well, OK.  LOC is also 16 years old, and GPOS is 18 years old. So what?

R's,
John

PS: I agree with all of Brad's arguments why a well known URL is the
least bad option.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 24 Nov 2012 17:51:25 -0800

> well, it is implemented and heavily in use for 80% of the tablet market, 33% of smartphone market and 15% of the laptop market.

...but 0% of the JavaScript market. JavaScript in browsers, *by design*, has no ability to send requests other than HTTP. There is no equivalent of gethostbyname(), much less getsomednsrrtype().

If you want JavaScript to be a general-purpose language with the ability open TCP/UDP sockets at will, that's fine, but that would invoke a very different security model for JavaScript.

--Paul Hoffman

---

From: James M Snell <[email-masked]>
Date: Sat, 24 Nov 2012 19:08:29 -0800

On Sat, Nov 24, 2012 at 5:51 PM, Paul Hoffman <[email-masked]> wrote:

> >> I.e. SRV was first specified in RFC 2052, released in october 1996. I
> mean, for how long time is it ok to claim it is a "new thing" that people
> have not implemented it, and when will people require it?
> >>
> >> 1996 is now 16 years go!
> >>
> > well, it is implemented and heavily in use for 80% of the tablet market,
> 33% of smartphone market and 15% of the laptop market.
>
> ...but 0% of the JavaScript market. JavaScript in browsers, *by design*,
> has no ability to send requests other than HTTP. There is no equivalent of
> gethostbyname(), much less getsomednsrrtype().
>
>
Indeed... that does not necessarily mean the browser could not provide
indirect mechanisms for sending such requests. A simple name lookup api
with an implementation managed by the browser could prove to be quite
useful for a range of problems. It does come down to demand, however. The
browser vendors are not going to implement support for anything that there
is not an obvious demand for. WebFinger, by itself, would not be enough to
drive such demand, I think, but there are other efforts that might (such as
http/2).

- James

> If you want JavaScript to be a general-purpose language with the ability
> open TCP/UDP sockets at will, that's fine, but that would invoke a very
> different security model for JavaScript.
>
> --Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2012 04:03:37 -0000

>indirect mechanisms for sending such requests. ...

Note those words *by design*.  Javascript has a security model which,
as far as I can tell, the people complaining that it doesn't do SRV
don't realize that they don't understand.  It is not a bug that
Javascript scripts running in browsers can't go randomly opening ports
and devices.

It may be the case that it's possible to add SRV lookups and not break
the security model, although it's not obvious to me how that interacts
with the same-origin rule.  Poking around on the net, I don't see
anyone who's written anything about that.  It'd be a good place to start
if one were serious.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 24 Nov 2012 23:04:50 -0500

On Sat, Nov 24, 2012 at 05:51:25PM -0800, Paul Hoffman wrote:

>  If you want JavaScript to be a general-purpose language with the
> ability open TCP/UDP sockets at will, that's fine, but that would
> invoke a very different security model for JavaScript.

But at bottom, what the current discussion says is, "We want
JavaScript to be a full-force application writing language, but we
don't want all the crap that comes with that in our language, so we
want to add these three warts to the Internet instead."

As a personal disposition, I'm not opposed to warts where the virus is
dug in.  But this really is a basic architectural question for the
Area: do we even have a way of thinking coherently about the kinds of
applications that are written with deliberately-hobbled languages, but
that are widely deployed and broadly useful?  The debate on this topic
seems to say, "No."  Maybe that's our problem.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: James M Snell <[email-masked]>
Date: Sat, 24 Nov 2012 20:11:31 -0800

> anyone who's written anything about that.  It'd be a good place to start
The short version is that javascript should, in no way, be allowed to work
with raw ports within the browser. However, the browser is already doing
DNS lookups... a fairly simple API can be provided to allow javascript to
tap into that mechanism... something along the lines of..

  var nq = new NameQuery(".example.org",[NameQuery.SRV,NameQuery.CNAME],
callback)

Where the browser takes care of the details of interacting with the dns and
just passes the results off to the javascript. This allows the browser to
Do The Right Thing when it comes to managing security while giving the
javascript code access to the basic details.

Seems simple enough.

- James

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2012 04:30:37 -0000

>javascript code access to the basic details.

Hi.  How does this work with the same origin rule?

---

From: James M Snell <[email-masked]>
Date: Sat, 24 Nov 2012 20:36:48 -0800

Generally, the same origin rule would not apply. When some piece of
javascript uses the API, it's basically just asking the browser to do some
additional dns resolution using the same dns server it uses for it's own
resolution. The javascript does not gain access to anything more than what
the browser does. What the javascript gets back is just some basic
information about the name records, nothing more. The same origin rule does
not come into play until the script attempts to put that information to use
via ajax calls, etc.

- James

---

From: "John R Levine" <[email-masked]>
Date: 24 Nov 2012 23:49:15 -0500

> not come into play until the script attempts to put that information to use

Well, OK.  You do a SRV lookup, you get a host name and a port number, 
which are probably not the host name and port number your script came 
from.  Keeping in mind the same origin rule, what do you do with it?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 25 Nov 2012 01:23:00 -0500

Kingsley,

The question you ask, I would ask. How do you publish WebFinger documents in a nontypical place and expect them to be found?

As few comments/questions...
* Note that we only have the webfinger resource now and there is no .json part
* Why could you not publish information at Dropbox or elsewhere as and provide a pointer to it via your WebFinger account?
* Why wouldn't Dropbox or others provide WebFinger service? If they did, you could use the as acct link relation to then point from one account to another

Paul

-------- Original Message --------
From: Kingsley Idehen <[email-masked]>
Sent: Sat Nov 24 14:32:40 EST 2012
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked], Brad Fitzpatrick <[email-masked]>, John Bradley <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/24/12 11:21 AM, Paul E. Jones wrote:
> I don't understand how this would work. Suppose I write a client that 
> wants to look up information on a given user. Using the well-known 
> location, the client code is fairly simple. If we use different paths, 
> we'd need a discovery mechanism for the path, no?

Scenario:

I am an end-user with an account with a web file service provider. The 
service provider allows me to save files to a drive which are then Web 
accessible via URLs. I stumble across Webfinger and I decide I want to 
publish my profile data by leveraging the combined prowess of of an 
acct: scheme URI and a URL that denotes my profile document.

How do I achieve the above if I don't have the ability to create any of 
the following:

1. <http://dropbox.com/.well-known/webfinger 
<http://host.com/.well-known/webfinger>> or
2. <http://dropbox.com/.well-known/webfinger.json 
<http://host.com/.well-known/webfinger>> .

Imagine if all I had to do was create:

1. <http://dropbox.com/.well-known/{my-dropbox-collection}/webfinger 
<http://host.com/.well-known/webfinger>> or
2. 
<http://dropbox.com/.well-known/{my-dropbox-collection}/webfinger.json 
<http://host.com/.well-known/webfinger>> .

I can then make either of the above discoverable by sharing these URLs 
via my G+, LinkedIn, Twitter etc.. provided home pages, ditto my blog 
home pages, and even my personal Web site home page etc.. All of this is 
achieved without me knowing anything about:

1. DNS server config
2. Web server config -- including redirects.

I believe Webfinger fundamentally seeks to solve two critical problems 
for profile document authors:

1. self denotation via acct: scheme URIs
2. association self denotation with a self curated profile document -- 
so the acct: scheme URI basically resolves to a profile document.

Right now, Webfinger is only addressing the needs of service providers 
whereas it could also add granularity that enables individuals exploit 
the protocol, especially with the prevalence of storage oriented 
services from the likes of: Dropbox, Amazon S3, Google Drive, Microsoft 
Skydrive, Box.NET, Wuala, and many others. All an end-user has to do is 
mount one of those services and simply save their xml or json based 
profile document to the Web.

Webfinger application developers end up with a much richer and denser 
Web of Webfinger accessible profile documents, just like that :-)

Kingsley

> *Sent:* Sat Nov 24 11:05:58 EST 2012
> *Cc:* "Paul E. Jones" <[email-masked]>, Brad Fitzpatrick 
> <[email-masked]>, John Bradley <[email-masked]>, 
> "[email-masked]" <[email-masked]>
>> You can always redirect requests elsewhere, but if we don't have 
>> fixed resource locations, it makes discovery a challenge.
>>
>> _Paul_
>>
>
> Right now, Webfinger scopes everything to the "host" in a Web realm 
> that is really scoped to documents (Web 1.0 and 2.0) and named 
> entities (Web 3.0 via Linked Data).
>
> needs of profile document owners and individuals that seek full 
> control over their digital identities.
>
>>>     problem – and that the consequences of not solving the problem
>>>     in a practically implementable standards-based manner could once
>>> discussion happening on a mailing list other than apps-discuss 
>>> and/or [email-masked] <mailto:[email-masked]>?
>>>
>>>  There will many more clients than servers, so it needs to be hard 
>>> to get wrong, if we want people to do the right thing.
>>>
>>> work otherwise.  That's where I fear this is all heading:  because 
>>> of a misguided desired to make things easier for some hypothetical 
>> Goal: to be able to deploy a Webfinger accessible profile document 
>> via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, 
>> Wuala, Amazon S3 buckets etc.. Basically, removing the HTTP server 
>> ownership and admin requirement by moving scope to a document path 
>> rather than a host.
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 25 Nov 2012 08:45:49 +0100

> If you want JavaScript to be a general-purpose language with the ability open TCP/UDP sockets at will, that's fine, but that would invoke a very different security model for JavaScript.

Maybe that is a sign that JavaScript should only be used for plain old "web" and not do other kind of transactions like trying to send IP packets over HTTP etc.

I.e. if the design is to not do anything else than "fetch web pages", then maybe that is where it should stop.

On the other hand, if one with JavaScript want to do A and B and C (which I hear here in this discussion) maybe something should be changed in JavaScript. So that for example it can do WebFinger (including using SRV records -- which btw I think JavaScript should use for "normal web page fetching" as well).

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 25 Nov 2012 11:52:51 +0100

On 25 nov 2012, at 02:59, "John Levine" <[email-masked]> wrote:

> add SRV lookups, it's not because they are stupid.

Who has to do that persuasion?

Is it not the users of JavaScript that want a more powerful "http lookup" function that should ensure the call in JavaScript that is used do not only A+AAAA lookup but also SRV?

I.e. is it not part of an initiative like this, that want some service discovery, to ensure JavaScript is doing The Right Thing?

I do not think the programmer that writes JavaScript stuff should be able to do SRV lookups or access sockets directly. The programmer should still "only" fetch whatever data they want.

It is JavaScript that should be changed.

Is there anyone reading this thread that is involved in JS evolution?

   Patrik

---

From: Blaine Cook <[email-masked]>
Date: Sun, 25 Nov 2012 11:32:39 +0000

+1 to everything Tim says here, especially the implications of the rel
parameter on static hosting environments. I think Tim's suggestion that for
very small domains, just listing out each user as a static file is a great
/ simple alternative to the host-meta template redirect that I've been
advocating for.

b.

On 24 November 2012 06:32, Tim Bray <[email-masked]> wrote:

> Oops, I replied to this but hadn’t bothered to join the mailing list
> first, so it bounced.  Here it is again:
>
> accounts.  I could drop static JRD files into a small number of files with
> names like /.well-known/webfinger?**resource=mailto:tbray@**textuality.com<[email-masked]>and do webfinger very cheaply. The existence of the “rel” parameter means I
> I have to say this feels fanciful. Any time an example requires inventing
> a new URI scheme, I suggest that’s a symptom of trying too hard.
>
> [5.1, first para]
>
> define any semantic for this element. You probably need a  policy on
> unknown fields. For example:
> [7. Access Control] This section could be dropped, or replaced with a
> short paragraph noting that since WebFinger is based on HTTP,  implementors
> will need to deal with the possibility that the origin server may impose
> access control policies or simply refuse access.
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Nov 2012 07:24:43 -0800

> seems to say, "No."  Maybe that's our problem.

Excellent summary. Your conclusion of "no" seems correct, as does "Maybe that's our problem".

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2012 16:01:59 -0000

><http://host.com/.well-known/webfinger>> .

The answer is to persuade your provider to support webfinger URLs, or
to find a better provider.  No matter what discovery scheme we decide
on, there will be some existing providers that can't support it
without changing something.

Adding permanent warts to a design to work around a few individual
providers' current limitations is never a good idea.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sat, 24 Nov 2012 12:06:49 -0800

Kingsley,

WebFinger aims to solve exactly one problem:

  -- given a string that looks like "[email-masked]" (which may not be an
email address),
  -- find a metadata document for that user.

When Paul kindly told you that your proposal makes "discovery" more
difficult, he was asking how you meant to solve WebFinger's singular
function with your path-including scheme.  i.e. what are the steps to go
from "[email-masked]" to the final URL?

It's clear that you want to host something on Dropbox, but I'm not sure
it'll ever be your WebFinger document, not without Dropbox's cooperation.
 If you actually want to be in control of your identity, you really want
your own domain name.

- Brad

On Sat, Nov 24, 2012 at 11:32 AM, Kingsley Idehen <[email-masked]>wrote:

> location, the client code is fairly simple. If we use different paths, we'd
> need a discovery mechanism for the path, no?
>
>
> Scenario:
>
> publish my profile data by leveraging the combined prowess of of an acct:
> scheme URI and a URL that denotes my profile document.
>
> 1. <http://dropbox.com/.well-known/webfinger<http://host.com/.well-known/webfinger>>
> or
> 2. <http://dropbox.com/.well-known/webfinger.json<http://host.com/.well-known/webfinger>>
> .
>
> 1. <http://dropbox.com/.well-known/{my-dropbox-collection}/webfinger<http://host.com/.well-known/webfinger>>
> or
> 2. <http://dropbox.com/.well-known/{my-dropbox-collection}/webfinger.json<http://host.com/.well-known/webfinger>>
> .
>
> I can then make either of the above discoverable by sharing these URLs via
> my G+, LinkedIn, Twitter etc.. provided home pages, ditto my blog home
> pages, and even my personal Web site home page etc.. All of this is
> I believe Webfinger fundamentally seeks to solve two critical problems for
> profile document authors:
>
> 2. association self denotation with a self curated profile document -- so
> the acct: scheme URI basically resolves to a profile document.
>
> whereas it could also add granularity that enables individuals exploit the
> protocol, especially with the prevalence of storage oriented services from
> the likes of: Dropbox, Amazon S3, Google Drive, Microsoft Skydrive,
> Box.NET, Wuala, and many others. All an end-user has to do is mount one of
> those services and simply save their xml or json based profile document to
> the Web.
>
> Webfinger application developers end up with a much richer and denser Web
> of Webfinger accessible profile documents, just like that :-)
>
>
> Kingsley
>
>
> Paul
>
> *From:* Kingsley Idehen <[email-masked]> <[email-masked]>
> *Cc:* "Paul E. Jones" <[email-masked]> <[email-masked]>,
> Brad Fitzpatrick <[email-masked]> <[email-masked]>, John
> Bradley <[email-masked]> <[email-masked]>, "[email-masked]"<[email-masked]>
> <[email-masked]> <[email-masked]>
> *Paul*
> is really scoped to documents (Web 1.0 and 2.0) and named entities (Web 3.0
> via Linked Data).
>
> *From:* Kingsley Idehen <[email-masked]> <[email-masked]>
> *Cc:* Brad Fitzpatrick <[email-masked]> <[email-masked]>, John
> Bradley <[email-masked]> <[email-masked]>, "[email-masked]"<[email-masked]>
> <[email-masked]> <[email-masked]>
>  There will many more clients than servers, so it needs to be hard to get
> wrong, if we want people to do the right thing.
>
> A late in the game request. Is there any chance of <
> host.com/.well-known/{path}/webfinger<http://host.com/.well-known/webfinger>>
> and/or <host.com/{path}/.well-known/webfinger<http://host.com/.well-known/webfinger>>
> instead of just <host.com/.well-known/webfinger> or <
> host.com/.well-known/webfinger> ?
>
> Goal: to be able to deploy a Webfinger accessible profile document via the
> likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, Amazon
> S3 buckets etc.. Basically, removing the HTTP server ownership and admin
> requirement by moving scope to a document path rather than a host.
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2012 16:32:00 -0000

>Who has to do that persuasion?

People who think doing SRV lookups is a good idea.  You, perhaps.

>I.e. is it not part of an initiative like this, that want some service
>discovery, to ensure JavaScript is doing The Right Thing?

Presumably, but arguments that end at "add SRV to Javascript" are not
productive.

It is not clear to me even at what level it would be appropriate to do
SRV lookups.  One possibility might be new builtin JS functions,
although I don't understand at this point how that would interact with
the single origin rule.  

Another possibility is a new URL scheme, along the lines
of draft-jennings-http-srv, or more generally like this:

  srv[s]://example.com:foo/bar 

does a SRV looksup of 

  _foo._tcp.example.com

and turns the request into

  http[s]://<target>:<port>/bar

(Add hand waving about what to do with the priority and weight if
there are multiple answers, along the lines of what it already does
with multiple A or AAAA answers.)

If people think this is a good idea, they sould write it up and try
implementing it in some of the open source browsers that people use.
Or else stop kvetching.

R's,
John

---

From: James M Snell <[email-masked]>
Date: Sun, 25 Nov 2012 09:11:27 -0800

> although I don't understand at this point how that would interact with
Again, it doesn't interact at all with the same origin policy. The SRV
record information would be used to construct urls that contain the
appropriate domain and port. How those urls are then put to use is a
separate matter entirely..it's only at that point where things like the
same origin policy come into play. It would be handled no differently than
any other url used in the javascript code.

- James

---

From: William Mills <[email-masked]>
Date: Sun, 25 Nov 2012 09:21:01 -0800 (PST)

The way to solve this for JS in my opinion is to wrap this into the XHTTP handler and have that thing understand wf: or acct: scheems and do the SRV lookup inside that thing.  How that would work right with same origin is still an excellent question.

> From: John Levine <[email-masked]>
>To: [email-masked] 
>Sent: Sunday, November 25, 2012 8:32 AM
>Subject: Re: [apps-discuss] SRV and service discovery, draft-ietf-appsawg-webfinger-04
>

---

From: Graham Klyne <[email-masked]>
Date: Sun, 25 Nov 2012 23:35:34 +0000

> Excellent summary. Your conclusion of "no" seems correct, as does "Maybe that's our problem".

What I've read of this discussion hasn't addressed the consideration that for 
Javascript *in browser*, a typical user doesn't get to choose what programs are 
run on their machine.  It's not Javascript the language that's the problem, but 
the way that code is delivered and executed.

(This does not, of itself, argue against supporting, say, DNS SRV lookups, but 
access to any such capability has to be approached somewhat conservatively 
compared with most other programming platforms for Internet access.)

#g
--

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 26 Nov 2012 09:47:20 +0900

On 2012/11/26 8:35, Graham Klyne wrote:

> What I've read of this discussion hasn't addressed the consideration
> that for Javascript *in browser*, a typical user doesn't get to choose
> what programs are run on their machine. It's not Javascript the language
> that's the problem, but the way that code is delivered and executed.
>
> (This does not, of itself, argue against supporting, say, DNS SRV
> lookups, but access to any such capability has to be approached somewhat
> conservatively compared with most other programming platforms for
> Internet access.)

Yes indeed. Server-side JavaScript isn't an issue at all. There are many 
server-side JavaScript implementations (see e.g. 
http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions), 
and checking the most well-known of them, it has DNS support (see 
http://nodejs.org/api/dns.html; I'm not a DNS expert and so can't judge 
whether these functions are adequate for our problem or not).

The problem is *browser-side* JavaScript. I have fixed that in the 
subject. As it currently stands, any web page can execute any JavaScript 
code from any source.

Here is a hopefully somewhat realistic example of what might happen when 
allowing DNS access from brwser-side JavaScript:

Employee A at company B visits web site C over lunch. Web site C 
includes (or points to) JavaScript that scans company B's DNS system to 
figure out its structure and detect potential weak points. This 
information is sent back to C without A noticing. As a result, 
information about B (e.g. internal structure, new but as of yet secret 
products,...) and its network infrastructure may leak to C.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 26 Nov 2012 10:05:23 +0900

> The way to solve this for JS in my opinion is to wrap this into the XHTTP handler and have that thing understand wf: or acct: scheems and do the SRV lookup inside that thing.  How that would work r…

Yes. Assume the user has used some authentication to access some 
webfinger data in the past. Then a third-party web page tries to access 
the corresponding acct: URI/IRI and gets the data and sends it to the 
third-party web server. That would be bad.

What would be okay is that the user activates (clicks on) an acct: link, 
and the webfinger information is shown as a separate "page" (or whatever 
the implementation things is best to show the information) independent 
of the page the link was on. That's what currently happens with any kind 
of link, from http: to mailto:.

It might also be okay, under same-origin restrictions, to get acct: data 
from the same origin as the web-page. But that of course has to be 
carefully evaluated for security risks. Especially for multi-hosting 
sites, it may not be a good idea.

Regards,   Martin.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 25 Nov 2012 22:57:45 -0500

Lets take a step back, what is the appropriate level of abstraction for
Javascript client service discovery?

I don't think we want a Jscript client to be aware of the transport
protocol if at all possible. The application layer should be properly
abstracted away from the transport layer. Even if the only network is
TCP/IP, the application layer should still be properly abstracted.

We are pretty much wedged into IP indefinitely but changing the TCP part is
feasible. And limitations of JScript should not be an obstacle to doing the
right thing.

So I don't think we want to have a full DNS stack in there. But that does
not mean we should be limited to nothing more than A-records.

Instead I would like a JScript call of the form 'open me a connection to
the service X at DNS name Y using the Z discovery mechanism.

'Use SRV' would be one option, 'Use A/AAAA' would be another. But the call
should also allow the application to just leave that to the platform to
make the best choice.

I can't see the justification for complaining about 'warts'. The IETF
should have addressed discovery more systematically a long time back. Well
known ports are not a viable mechanism any longer. The fault here is on the
IETF side for not giving clear and workable guidance a decade ago.

That said, I do agree that JScript is an abominable creation. Since I
turned it off by default four weeks ago my Web browsing experience has
improved dramatically. Pop up ads are gone completely. So are the more
incompetent and idiotic site hacks. Sites that used to load slowly now load
much faster. I turn scripting on on a case by case basis.

---

From: John Bradley <[email-masked]>
Date: Mon, 26 Nov 2012 12:18:25 -0300

I don't get it ether where is this path coming from?

John B.
On 2012-11-24, at 1:21 PM, "Paul E. Jones" <[email-masked]> wrote:

> Yes, but I am seeking a way to alleviate the following challenges for end-users seeking to exploit Webfinger:
> 
> 1. domain ownership
> Right now, Webfinger scopes everything to the "host" in a Web realm that is really scoped to documents (Web 1.0 and 2.0) and named entities (Web 3.0 via Linked Data). 
> 
> Is it too costly to add "paths" to Webfinger bearing in mind the granularity this option provides i.e., rather being aimed at service providers (who control domain name and web servers) it also serves the needs of profile document owners and individuals that seek full control over their digital identities. 
> 
>> A late in the game request. Is there any chance of <host.com/.well-known/{path}/webfinger> and/or <host.com/{path}/.well-known/webfinger> instead of just <host.com/.well-known/webfinger> or <host.com/.well-known/webfinger> ? 
>> 
>> Goal: to be able to deploy a Webfinger accessible profile document via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, Amazon S3 buckets etc.. Basically, removing the HTTP server ownership and admin requirement by moving scope to a document path rather than a host. 
>> 
>> -- 
>> 
>> Regards,
>> 
>> Kingsley Idehen       
>> Founder & CEO 
>> OpenLink Software

---

From: Nico Williams <[email-masked]>
Date: Mon, 26 Nov 2012 09:48:08 -0600

> seems to say, "No."  Maybe that's our problem.

Whatever else may be hiding in this I-D, service discovery is not a
wart.  Indeed, proper service discovery is sorely missing.

The nice thing about XHR is that the implementation can hide all sorts
of details and still apply same-origin policies.  Any service
discovery functionality to be implemented in JS will have to fit into
XHR, so that the implementation of it does all the work.  This means
that service discovery must either be new options to XHR or a new URI
scheme.  The rest is details.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Nov 2012 08:45:17 -0700

On 11/23/12 11:32 PM, Tim Bray wrote:

> [5.4] Two problems: First, this section fails to convince me that
> the “acct” scheme is worth the effort.

Presumably that's a job for draft-ietf-appsawg-acct-uri.

> Second, the section could simply say that the URI used to identify
> the entity being queried is not tied to any scheme; the arm-waving
> about the hypothetical wonderfulnesss of “acct:” is a waste of
> space.  Then having done that, the section could be replaced by a
> one-line note in section 5.1

+1

Peter

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

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 26 Nov 2012 20:24:31 +0000

>from.  Keeping in mind the same origin rule, what do you do with it?

AFAIK, JavaScript does not get access to the results of the A/AAAA query
before a page is loaded today.  Imagine the following scenario:

- User A on Network N requests page P
- P contains an attacker's JavaScript
- N is using split DNS; queries on that network return different results
than queries externally, presumably for perceived security reasons
- Without some same origin rules, P now has access to sensitive information
- For example, the server behind P does reverse-DNS lookup on the source
IP address for the initial request, guesses a domain for A, let's say
"example.com", then passes that information to the JavaScript in P using
AJAX
- P now does SRV queries for _ldap._tcp.example.com, and starts attacking
your internal, poorly-secured LDAP server using CORS AJAX/WebSocket
requests.

I'm not sure it's possible to describe other DNS queries as being
same-origin to P; by definition, they're liable to be different for names
or ports, or you would already know the answer.

-- 
Joe Hildebrand

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 26 Nov 2012 20:30:27 +0000

>products,...) and its network infrastructure may leak to C.

Sorry, I replied without having read this whole thread (since the subject
changed).  My example is effectively the same as Martin's.

-- 
Joe Hildebrand

---

From: James M Snell <[email-masked]>
Date: Mon, 26 Nov 2012 12:41:56 -0800

This case definitely points to why raw sockets or an "unmanaged" dns client
mechanism for javascript would definitely not be desirable. To mitigate
this case, a "name query" api could be limited to allow only queries for
the current domain and it's subdomains. That is, if I'm loading a page from
"example.org", then doing a name query for "_webfinger._tcp.example.org."
would be acceptable but "_webfinger._tcp.example.com" would not.

- James

---

From: John Bradley <[email-masked]>
Date: Mon, 26 Nov 2012 17:51:50 -0300

That would largely kill the main use of WF to get information about people in other domains.

It is not an easy problem to solve.  We looked at all sorts of DNS based solutions in openID Connect but none of them were practical.

John B.
On 2012-11-26, at 5:41 PM, James M Snell <[email-masked]> wrote:

> This case definitely points to why raw sockets or an "unmanaged" dns client mechanism for javascript would definitely not be desirable. To mitigate this case, a "name query" api could be limited to allow only queries for the current domain and it's subdomains. That is, if I'm loading a page from "example.org", then doing a name query for "_webfinger._tcp.example.org." would be acceptable but "_webfinger._tcp.example.com" would not. 
> 
> - James
> 
> 
> On Mon, Nov 26, 2012 at 12:30 PM, Joe Hildebrand (jhildebr) <[email-masked]> wrote:

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 26 Nov 2012 16:08:56 -0500

Well maybe a scheme such as WebFinger is just not suitable as an
application that downloads from a Web Page and then just runs without any
user intervention.

I don't see any particular problem with JScript using SRV rather than A
records to bind TCP sockets.

I do see a big problem with JScript being able to make a query to what is
likely to be a private service on the user's behalf

No, the fact that some people think of Web Finger as being strictly public
information does not mean that the information about myself that I am
willing to reveal to Alice is the same as the information I am willing to
reveal to Bob.

For example, I might be looking to have an affair with Alice and so I have
included my private Skype account so that she can call me. This is
information that I do not want her husband (Bob) to know for obvious
reasons.

Even if you decide to dumb down Web finger so that it is  only delivering
public data you cannot expect us to dumb down the rest of the Web to match.

The fundamental problem here is that Web Finger is precisely the type of
capability that makes JScript a very very bad idea.

On Mon, Nov 26, 2012 at 3:51 PM, John Bradley <[email-masked]> wrote:

> It is not an easy problem to solve.  We looked at all sorts of DNS based
> solutions in openID Connect but none of them were practical.
>
> John B.
>
> This case definitely points to why raw sockets or an "unmanaged" dns
> client mechanism for javascript would definitely not be desirable. To
> mitigate this case, a "name query" api could be limited to allow only
> queries for the current domain and it's subdomains. That is, if I'm loading
> a page from "example.org", then doing a name query for "_webfinger._
> tcp.example.org." would be acceptable but "_webfinger._tcp.example.com"
> would not.
>
> - James
>
>

-- 
Website: http://hallambaker.com/

---

From: Mike Jones <[email-masked]>
Date: Wed, 28 Nov 2012 00:12:31 +0000

Thanks, Tim, for this fresh read.  I wanted to write and specifically agree with a number of them and comment on a few.  In fact, I agree with all of them, other than where noted.  My comments are interspersed below, prefixed by "Mike>".

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Friday, November 23, 2012 5:34 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

Sorry for coming late to the party. This the first webfinger draft that I've ever read, and I'm almost completely ignorant of the history.  Having said that, sometimes a history-free pair of eyes looking at something can add value.

[1. Introduction. ]

Suggest shortening up, omitting the history, losing the whole first para and beginning the second "Webfinger uses the HTTP protocol to retrieve a structured document containing link relations that describe people or other entities on the Internet. For a person...

Mike> Agreed - less is more here

[para 2]  "direct human consumption (e.g., looking up someone's phone number), or..."

[4. Example use of WebFinger] Tighten up 1st sentence: "This section shows a few sample uses of Webfinger."

What is the benefit of the "aliases" field?

Mike> Expanding on this, I don't understand the need for either the "aliases" or "properties" parameters.  I'd omit them.  Keep "links", "rel", "type", and "href".  (This was discussed on yesterday's OpenID Connect call, and Tim and others felt that the WebFinger spec should define the meanings of the fields used.  Yes, this would mean copying some text from the XRD spec, but then at least the WebFinger spec could be read in a self-contained fashion.  And yes, this is a change of position for me. :-) )

What is the benefit of the "acct" URI scheme?  Couldn't "mailto:" have been used in this case?

Mike> I'm OK with keeping the acct: usage, provided that the acct: URI scheme makes timely progress.  I value the conceptual distinction from mailto:, since acct:[email-masked] is a legitimate account identifier, but not an e-mail address.  (Tim, see http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-01, if you haven't already.)

Since the "rel" parameter is optional and you can't count on it, providing it is strictly a client-suggested optimization?  Feels quite likely to be premature, to me.

Mike>  I disagree with this comment.  "rel" is valuable to narrow down what's returned in the case that you know what you're looking for (which you usually do!).  I do think, though that this sentence needs to be added after the one about support being "OPTIONAL, but RECOMMENDED":  "Should the server not support the "rel" parameter, it MUST ignore it and process the request as if any "rel" parameter values were not present."  That way it's clear that clients are free to safely use it even when servers may not support it.

In particular, I'm thinking of my own small-scale domains like textuality.com and tbray.org, which have a single-digit number of accounts.  I could drop static JRD files into a small number of files with names like /.well-known/webfinger?resource=mailto:[email-masked] and do webfinger very cheaply. The existence of the "rel" parameter means I can't solve this problem statically.

I have to say this feels fanciful. Any time an example requires inventing a new URI scheme, I suggest that's a symptom of trying too hard.

[5.1, first para]

I hate to be pedantic, but when you say "parameter", you're talking about the &-separated name-value pairs in the "query" [RFC3986] part of a URI.  Fine enough, and it's a common usage, but I don't actually know where it's defined (not in 3986) so either we need to find a definition and link to it, or invest a paragraph in saying what you mean

[5.1] "WebFinger servers MUST return JRD documents as the default representation..." What does "default" mean?  Are we saying that servers MUST return JRD?  If so, say so.

Mike> Agreed.  Delete the words "as the default representation".

[5.1] Last two paragraphs are perhaps superfluous?  Since it's HTTP, don't you get this for free?

Mike>  I think these paragraphs are possibly valuable to implementers, even if superfluous.  Maybe reference 2616 in the first one as well and change "MAY" to "can" in the second, making it clear that this is not new normative text, but simply an implementation remark.

[5.2] "Any array elements within the "links" array are presented by the server in order of preference."  Huh? Don't understand.

[5.2] "The "template" element is forbidden"?  Huh?  The spec doesn't define any semantic for this element.
You probably need a  policy on unknown fields. For example:
(a) "Software must ignore any fields found in the JRD which are not specified here" (a.k.a. MUST_IGNORE)
(b) "It is forbidden for any elements not specified here to appear in a JRD" (a.k.a. maximally brittle) The special processing for "template" is just weird.  If it's required for some good reason, give the reason.

[5.2] The fact that "titles" is allowed but has no specified semantics is troublesome.  Explain or remove?
[5.2] The fact there is no discussion of what you might use "properties" for, nor any discussion of its structure, is troublesome.
 Do we have actual users of this?  Explain or remove?

[5.3] "The purpose of the "rel" parameter is to return a subset of resource's link relations.  It is not intended to reduce the work"
Could this be motivated a bit?  Why would you want a subset, aside from reducing the work?

Mike> Reducing bandwidth and latency is one reason.  Discovery is likely to be in the critical path of some user interface display actions, so latency matters.

[5.3] The restated example doesn't really add value here, I think. How the "rel" parameter works is simple enough.

[5.4] Two problems: First, this section fails to convince me that the "acct" scheme is worth the effort. Second, the section could simply say that the URI used to identify the entity being queried is not tied to any scheme; the arm-waving about the hypothetical wonderfulnesss of "acct:" is a waste of space.  Then having done that, the section could be replaced by a one-line note in section 5.1

Mike>  I'd leave the acct: text, pending the disposition of http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-01 hopefully becoming clear soon.

[5.5] Really?  Do we have any hard data that convinces us that there's an interesting class of organizations that (a) want to offer WebFinger and (b) can't access their root and (c) can easily set up a subdomain?

Mike>  Per private threads with Google, who first identified this need for OpenID 2.0 several years ago, apparently Google is willing to back off on this requirement (per Tim's note earlier today).

[6] "Enterprise"?! What does that word mean?  Also there's a contradiction between the sentence saying you have to use "*" and the next paragraph saying something more restrictive is OK.  Might it be better to just say "WebFinger may not be usable from code running in browsers due to Origin policies; therefore, the use of CORS headers is required. The header "Access-Control-Allow-Origin: * " will maximize usability; certain organizations may wish to control access to WebFinger with a more restrictive Access-Control-Allow-Origin value.

[7. Access Control]

This section could be dropped, or replaced with a short paragraph noting that since WebFinger is based on HTTP, implementors will need to deal with the possibility that the origin server may impose access control policies or simply refuse access.

Mike>  Agree that this could be tightened, but I disagree that it should be dropped.  This was added a few drafts ago to counter the perceptions that everything served by WebFinger must be public.

[8.]  This section could be dropped.  This is an HTTP-based service and we can assume that implementors should be prepared to handle HTTP-standard redirect semantics.

Mike>  I'd start by trying to replace this with a few tightly written sentences about standard HTTP redirect semantics applying.

The caution about not redirecting to a /.well-known somewhere else seems of questionable value, since I might actually want to have a common webfinger which returns the same values for any X whether it's [email-masked], [email-masked], or whatever, and I could do that efficiently by having a /.well-known on one of them and redirecting to it from the others.

>Mike>  I agree that the caution about where the service URL should point is misguided and should be deleted.

On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones <[email-masked]> wrote:
> received on -03 and adds the "webfinger" subdomain that was discussed 
> on the list this past week.  Specifically, here's what changed:
>
> *         Mention in section 2 that WebFinger uses the "rel" attribute and
> *         Changed the rel types in 4.3 and 4.4 to be URI-based (on
> example.net)
>
> I think we're getting closer, though I know the "webfinger" subdomain 
> might be a bit controversial.  I'm on the fence on this one, myself.  
> I can see the pros and cons of having it.  I'd prefer to stay out of 
> the debate, though.  I'll put into the document whatever the group 
> says to put into the documents :-)  That said, I think Mike made a 
> valid argument with respect to the fact that some domain owners have 
> no ability to do anything more than insert an A record for a subdomain.
>
>
>
> there is any response from a web server at the host, that means the 
> host does have the capability of providing WF services and the 
> "webfinger" subdomain should not be consulted.  Thus, the webfinger 
> subdomain would only be consulted if there is no web server running at 
> the host at all.  It's not a fallback for domain owners who have a web server, but just didn't install a WF server.
> For that case, they should use 3xx redirection for hosting the WF 
> server elsewhere.
>
>
>
> Paul
>
>
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Nov 2012 02:46:18 -0500

Tim,

Finally getting around to editing version -05.  I'll make some changes, but
some I don't entirely agree with.  Comments below: 

> and beginning the second "Webfinger uses the HTTP protocol to retrieve a
> structured document containing link relations that describe people or
> other entities on the Internet. For a person...

I've heard this request a few times.  I'll remove it and re-word it a bit.
 
> [para 2]  "direct human consumption (e.g., looking up someone's phone

Changed.
 
> shows a few sample uses of Webfinger."

Changed.
 
> What is the benefit of the "aliases" field?

Are you looking for justification of the field or want to know its use?  It
exists, because a user might be known by more than one identifier.  What is
probably more useful to a WF client is querying an HTTP URI and learning an
"acct" URI.  Presenting a friendly user@domain form to the user might be
desirable.

The primary motivation for including this in the example was to ensure every
element of the JRD was represented through examples.  This was something we
discussed at the IETF meeting.  The fields exist in JRD and, rather than
documenting them at length, just show examples.
 
> What is the benefit of the "acct" URI scheme?  Couldn't "mailto:" have

It could have been, but we had a very long debate on this.  Twitter, for
example, does not offer a mailto: form to its users.  If it provides WF
services, it would likely need something other than mailto:.  For this (and
other reasons), "acct" was proposed several years ago.

> Since the "rel" parameter is optional and you can't count on it,

I think Mike answered this one.  There is utility in using "rel" and for
servers to support it. It can allow both the client and server to work more
efficiently, use less bandwidth, etc.
 
> In particular, I'm thinking of my own small-scale domains like
> with names like /.well-
> known/webfinger?resource=mailto:[email-masked] and do webfinger
> very cheaply. The existence of the "rel" parameter means I can't solve
> this problem statically.

That's true.  Rather than using the "resource" parameter, there has been a
suggestion to use URIs of this form:

/.well-known/webfinger/acct:[email-masked]

The reason is that the ? would signal to many (all?) web servers that what
follow is a query string.
 
> inventing a new URI scheme, I suggest that's a symptom of trying too
> hard.

This sort of thing comes up time and again.  What was proposed a few years
ago was:

urn:host:hostname

Sine a hostname in DNS might map to multiple physical "things", it's perhaps
not the best syntax.  Nonetheless, there are "things" on the network that
need to be identified by name. I could have used the URI scheme "http", but
I wanted to use this as a means of further showing that WF can be used with
any URI scheme.  I did have a loud disclaimer that the example is entirely
fictitious.  Even so, I think the notion of using WebFinger to find out
information about a physical device on the network is useful.

> [5.1, first para]
> 
> I hate to be pedantic, but when you say "parameter", you're talking
> about the &-separated name-value pairs in the "query" [RFC3986] part of
> a URI.  Fine enough, and it's a common usage, but I don't actually know
> where it's defined (not in 3986) so either we need to find a definition
> and link to it, or invest a paragraph in saying what you mean

OK. I put that in Section 5.  It may not be the best place, but I do not
know where to put this odd text.  This is a generic paragraph that is mostly
applicable to any web service.  This is really not formally documented
anywhere?

> [5.1] "WebFinger servers MUST return JRD documents as the default
> representation..." What does "default" mean?  Are we saying that servers

The default representation is the one that would be returned if the client
requested no specific format or if the server supports no other format.
This language exists to allow for the possibility for a client to utilize
the Accept header to request a particular representation.  While no other
representation other than JRD is defined, I would prefer to not have
language that makes it impossible to utilize content negotiation should:

1) JRD falls out of favor one day
2) Some client and server implementation prefer to use something else
 
> don't you get this for free?

I think we need the next-to-the-last paragraph.  If the web server does not
have a WF resource, it will return a 404.  That's standard HTTP behavior.
However, if a client queries the WF server asking for a particular
"resource" that it does not know about, we need to describe what the server
should do.  I'm suggesting to use 404 again, as that seems most logical.
But, if I don't say so, somebody will ask what to do.

For the last paragraph, somebody explicitly asked for this text (and gave it
to me).  This one does seem somewhat redundant with the HTTP spec, but
somebody wanted it.  I think it might be useful since the JRD has an expires
element.
 
> [5.2] "Any array elements within the "links" array are presented by the
> server in order of preference."  Huh? Don't understand.

Yeah, that did sound bad.  I'm not sure my revised text is better.  How is
this:

"Array elements within the "links" array are presented by the server in
order of preference."

This is a question that has come up a few times.  "Does the order of link
relations matter?"  The answer is "yes".  If my WF server presents two
"avatars" for me, for example, my most-preferred "avatar" is the first one
in the array.

I welcome any suggested wording.
 
> define any semantic for this element.

The "template" element is defined in the XRD spec and used by RFC 6415.
However, we do not use that in WF.  Thus, servers should not send it.  A
client would not know what to do with it.  I'll add the language to ignore
unknown elements, but I need to say something about this "template" ...
servers should not be using that.

> (b) "It is forbidden for any elements not specified here to appear in a
> JRD" (a.k.a. maximally brittle) The special processing for "template" is
> just weird.  If it's required for some good reason, give the reason.

I'll got with (a). I prefer for clients to consume whatever they can
understand.
 
> is troublesome.  Explain or remove?

This is defined in the XRD spec.  An example is given in section 4.1 for the
"blog" (showing the title of the blog in two different languages).

> [5.2] The fact there is no discussion of what you might use "properties"
> for, nor any discussion of its structure, is troublesome.

Similar comment as above.  Properties actually have nice utility and an
example of their use is in Section 4.3.  In that example, the link relation
actually has no "href" value.  Instread, there is a "rel" and properties
associated with the "rel".  The properties define the host, port, and other
parameters to allow for an email client to auto-provision.
 
> [5.3] "The purpose of the "rel" parameter is to return a subset of
> resource's link relations.  It is not intended to reduce the work"

I think that sentence should go.  Asking for a specific "rel" certainly
could reduce server work.
 
> [5.3] The restated example doesn't really add value here, I think. How
> the "rel" parameter works is simple enough.

It seems simple, but I think there is value in keeping the text. Since we
allow the "rel" parameter to be presented more than once, I think it's
useful to show an example of the syntax.  A client looking two or three
specific things might use this syntax.  I think there would be questions
without a clear example.
 
> "acct" scheme is worth the effort. Second, the section could simply say
> that the URI used to identify the entity being queried is not tied to
> any scheme; the arm-waving about the hypothetical wonderfulnesss of
> "acct:" is a waste of space.  Then having done that, the section could

Without this text, people would immediately ask what URI scheme one should
use to find information for [email-masked].  After a million hours of
debate, I think there is general consensus to use the "acct" URI (which is
progressing separately).  That said, there was a desire to make it clear
that WF may be used with any URI.  I'm not trying to do hand-waving.  This
text came about as a result of a lot of discussion.
 
> [5.5] Really?  Do we have any hard data that convinces us that there's
> and (b) can't access their root and (c) can easily set up a subdomain?

That is now gone. :-)  (It was never in the TOC, either.  Even Word thought
it was a bad idea.)
 
> [6] "Enterprise"?! What does that word mean?  Also there's a
> contradiction between the sentence saying you have to use "*" and the
> better to just say "WebFinger may not be usable from code running in
> required. The header "Access-Control-Allow-Origin: * " will maximize

I've re-worded this a bit to try to address the conflicting language.

Enterprise...

http://www.tfd.com/enterprise:
  2. A business organization

We cannot just ignore the enterprise.  Seriously.
 
> [7. Access Control]
> 
> This section could be dropped, or replaced with a short paragraph noting
> that since WebFinger is based on HTTP, implementors will need to deal
> with the possibility that the origin server may impose access control
> policies or simply refuse access.

This came about due to concerns for data protection.  There are some
resources to which WF might refer that may only be accessed with a username
and password.  WF does not prevent such access control measures.  It just
provides pointers to the data.  Access to the data is not WF's problem.

I think we need to have something here, because this was a point of concern
and confusion.

I'm happy to tweak it, but I don't think we should remove it entirely.  If I
did, somebody would ask questions about protection of resources.
 
> [8.]  This section could be dropped.  This is an HTTP-based service and
> we can assume that implementors should be prepared to handle HTTP-
> standard redirect semantics.  The caution about not redirecting to a
> actually want to have a common webfinger which returns the same values
> for any X whether it's [email-masked], [email-masked], or whatever, and I
> could do that efficiently by having a /.well-known on one of them and
> redirecting to it from the others.

I think we need to keep this one, too.  Again, I'm not opposed to polishing
the language a bit, but questions related to hosting WF services elsewhere
will arise (and have arisen) and having this to explain the way it is done
is useful, I think.

I'll remove the "caution".  It's really not needed.

Paul

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 28 Nov 2012 07:06:35 -0800

> We cannot just ignore the enterprise.  Seriously.

I also object to the word "Enterprise".  We all know what a company is.

Is my neighborhood frozen banana stand an enterprise? No?
Is my Fortune 500 company? Yes?
Where's the line?

It's pointless to define what "Enterprise" means, so just avoid the word.
 You can say "those wanting a more restrictive policy can ....", then my
frozen banana stand competitors can't webfinger my prices from their
javascripts.

Using the word "enterprise" looks elitist and like companies are somehow
special-cased.