Subject: Re: [apps-discuss] Looking at Webfinger

From: George Fletcher <[email-masked]>
Date: Tue, 28 Aug 2012 11:09:26 -0400

Way "late to the party" but I can speak from experience that deployment 
can be a real issue in some environments. It's all really straight 
forward in a small company or an environment where the identity team 
"owns" the root domain (e.g. example.com). However, if an entire other 
group in a large organization "owns" the root domain (home page for the 
site) and the identity team then needs to get them to make changes, the 
deployment solution gets brittle pretty quick. I've had our webfinger 
support broken at least twice because the "other" team didn't know that 
certain configs were required:)

Also, installing the "dynamic pluming" can be more problematic is these 
cases. It is possible to get apache rewrite rules or netscaler magic in 
place to make it work, it's just a more brittle deployment architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer wrote:
> Mark -- Of course I was speaking about practical realities of typical 
> web server administration and deployment.  In practical terms, adding 
> a new mod_rewrite rule or moral equivalent is going to be easier than 
> adding a new PHP script that connects to a database.  The latter is 
> just always going to be a much higher bar.
>
> And, something that returns per-user data is generally going to need a 
> dynamic service of some kind, unless your site has just a handful of 
> users and you don't mind going through a publishing exercise each time 
> you add or change a user...
>
> None of this has anything to do with the interface, just deployment 
> realities.  And in reality all of this is going to need a dynamic 
> service somewhere for each non-trivial site, this is all just a 
> question of how to hook it up.
>
> --
> John Panzer / Google
> [email-masked] <mailto:[email-masked]> / abstractioneer.org 
> <http://www.abstractioneer.org/> / @jpanzer
>
>
>
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 05/07/2012, at 8:16 AM, John Panzer wrote:
>
>     > Just as a historical note.  The envisioned usage of host-meta
>     was originally to avoid a specification which mandated a
>     particular dynamic URL API at a particular /.well-known endpoint
>     (because it may not be feasible to do that across all
>     organizations and deployments).  The host-meta document itself
>     would be highly cacheable and so wouldn't incur an additional
>     network trip in the common case.
>     >
>     > Having a 3xx redirect is a reasonable alternative that allows a
>     similar escape hatch via something like mod_rewrite, albeit at the
>     cost of needing an additional network trip each time.  Since a
>     deployment can always avoid the 3xx redirect with additional
>     dynamic plumbing behind the well-known endpoint, I don't think
>     that's a horrible thing.
>     >
>     > An application-level redirect would be almost equivalent to an
>     HTTP redirect, but then there are two ways to do the same thing.
>      If _only_ an application-level redirect is allowed, then you have
>     to have at least a minimal dynamic service at the well-known
>     endpoint (no more mod_rewrite).  But the whole reason for this is
>     to avoid the requirement for a dynamic service behind well-known...
>
>     "dynamic" and "static" are properties of the implementation, not
>     the interface. HTTP doesn't require that any particular URL be
>     "dynamic"; anything can, with the right metadata, be cached (and
>     indeed, I've cached many, many things with the wrong metadata,
>     because of silly site operators and their ideas about "dynamic").
>
>     Now, if people want to target a particular implementation that
>     makes it easier to serve a particular style of URL without writing
>     code, fine, but let's not confuse things.
>
>     E.g., a URL like
>
>     http://example.com/.well-known/user/bob
>
>     is easy to serve in pretty much any way you like with Apache.
>
>     I'm also going to push back on the "it may not be feasible to do
>     that across all organizations and deployments" motivation. This is
>     a race to the bottom. The trick is to make it accessible enough to
>     get sufficient traction to pull everyone along, without pandering
>     to *everyone*'s requirements.
>
>     Regards,
>
>     --
>     Mark Nottingham http://www.mnot.net/
>
>
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 28 Aug 2012 15:17:19 -0400

George,

I believe it might be useful to introduce those who break your WebFinger
server to Louisville Slugger. :)

Your pain is understood, but I do not see a way to avoid it.  We could
introduce something in DNS, but that would also present challenges.  No
matter where we "root" the discovery process, there is a potential somebody
could break it.  It could be rooted somewhere other than the root of the
domain (e.g., webfinger.example.com), but we either need to decide in
advance of such a location or introduce a way to discovery the discovery
resources.

Do you have a suggestion that would make this less likely to be broken?

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

Way "late to the party" but I can speak from experience that deployment can
be a real issue in some environments. It's all really straight forward in a
small company or an environment where the identity team "owns" the root
domain (e.g. example.com). However, if an entire other group in a large
organization "owns" the root domain (home page for the site) and the
identity team then needs to get them to make changes, the deployment
solution gets brittle pretty quick. I've had our webfinger support broken at
least twice because the "other" team didn't know that certain configs were
required:)

Thanks,
George

Mark -- Of course I was speaking about practical realities of typical web
server administration and deployment.  In practical terms, adding a new
mod_rewrite rule or moral equivalent is going to be easier than adding a new
PHP script that connects to a database.  The latter is just always going to
be a much higher bar. 

And, something that returns per-user data is generally going to need a
dynamic service of some kind, unless your site has just a handful of users
and you don't mind going through a publishing exercise each time you add or
change a user...

None of this has anything to do with the interface, just deployment
realities.  And in reality all of this is going to need a dynamic service
somewhere for each non-trivial site, this is all just a question of how to
hook it up.

--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/>  /
@jpanzer

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <[email-masked]> wrote:

On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note.  The envisioned usage of host-meta was
originally to avoid a specification which mandated a particular dynamic URL
API at a particular /.well-known endpoint (because it may not be feasible to
do that across all organizations and deployments).  The host-meta document
itself would be highly cacheable and so wouldn't incur an additional network
trip in the common case.
>
> Having a 3xx redirect is a reasonable alternative that allows a similar
escape hatch via something like mod_rewrite, albeit at the cost of needing
an additional network trip each time.  Since a deployment can always avoid
the 3xx redirect with additional dynamic plumbing behind the well-known
endpoint, I don't think that's a horrible thing.
>
> An application-level redirect would be almost equivalent to an HTTP
redirect, but then there are two ways to do the same thing.  If _only_ an
application-level redirect is allowed, then you have to have at least a
minimal dynamic service at the well-known endpoint (no more mod_rewrite).
But the whole reason for this is to avoid the requirement for a dynamic
service behind well-known...

"dynamic" and "static" are properties of the implementation, not the
interface. HTTP doesn't require that any particular URL be "dynamic";
anything can, with the right metadata, be cached (and indeed, I've cached
many, many things with the wrong metadata, because of silly site operators
and their ideas about "dynamic").

Now, if people want to target a particular implementation that makes it
easier to serve a particular style of URL without writing code, fine, but
let's not confuse things.

E.g., a URL like

I'm also going to push back on the "it may not be feasible to do that across
all organizations and deployments" motivation. This is a race to the bottom.
The trick is to make it accessible enough to get sufficient traction to pull
everyone along, without pandering to *everyone*'s requirements.

Regards,

---

From: John Bradley <[email-masked]>
Date: Tue, 28 Aug 2012 15:28:39 -0400

There are cases where there are hosted domains (Google etc) that may not have a http host for the domain name used in the users email address.  

There may be merit to having a webfinger.example.com fallback where the client can't reach the .well-known for the primary host.

I know that some sort of SRV record would be the correct way to do it, but in the real world SMB don't enter SRV records even if there DNS provider support them.
The most you can get them to do is add a CNAME or MX record.

Supporting these sorts of domains somehow is a important issue.

John B.

On 2012-08-28, at 3:17 PM, "Paul E. Jones" <[email-masked]> wrote:

> George,
>  
> I believe it might be useful to introduce those who break your WebFinger server to Louisville Slugger. :)
>  
> Your pain is understood, but I do not see a way to avoid it.  We could introduce something in DNS, but that would also present challenges.  No matter where we “root” the discovery process, there is a potential somebody could break it.  It could be rooted somewhere other than the root of the domain (e.g., webfinger.example.com), but we either need to decide in advance of such a location or introduce a way to discovery the discovery resources.
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
> Way "late to the party" but I can speak from experience that deployment can be a real issue in some environments. It's all really straight forward in a small company or an environment where the identity team "owns" the root domain (e.g. example.com). However, if an entire other group in a large organization "owns" the root domain (home page for the site) and the identity team then needs to get them to make changes, the deployment solution gets brittle pretty quick. I've had our webfinger support broken at least twice because the "other" team didn't know that certain configs were required:)
> 
> Also, installing the "dynamic pluming" can be more problematic is these cases. It is possible to get apache rewrite rules or netscaler magic in place to make it work, it's just a more brittle deployment architecture.
> 
> Thanks,
> George
> 
> Mark -- Of course I was speaking about practical realities of typical web server administration and deployment.  In practical terms, adding a new mod_rewrite rule or moral equivalent is going to be easier than adding a new PHP script that connects to a database.  The latter is just always going to be a much higher bar.
>  
> And, something that returns per-user data is generally going to need a dynamic service of some kind, unless your site has just a handful of users and you don't mind going through a publishing exercise each time you add or change a user...
>  
> None of this has anything to do with the interface, just deployment realities.  And in reality all of this is going to need a dynamic service somewhere for each non-trivial site, this is all just a question of how to hook it up.
> 
> --
> John Panzer / Google
> [email-masked] / abstractioneer.org / @jpanzer
>  
>  
> 
> > Just as a historical note.  The envisioned usage of host-meta was originally to avoid a specification which mandated a particular dynamic URL API at a particular /.well-known endpoint (because it may not be feasible to do that across all organizations and deployments).  The host-meta document itself would be highly cacheable and so wouldn't incur an additional network trip in the common case.
> >
> > Having a 3xx redirect is a reasonable alternative that allows a similar escape hatch via something like mod_rewrite, albeit at the cost of needing an additional network trip each time.  Since a deployment can always avoid the 3xx redirect with additional dynamic plumbing behind the well-known endpoint, I don't think that's a horrible thing.
> >
> > An application-level redirect would be almost equivalent to an HTTP redirect, but then there are two ways to do the same thing.  If _only_ an application-level redirect is allowed, then you have to have at least a minimal dynamic service at the well-known endpoint (no more mod_rewrite).  But the whole reason for this is to avoid the requirement for a dynamic service behind well-known...
> 
> "dynamic" and "static" are properties of the implementation, not the interface. HTTP doesn't require that any particular URL be "dynamic"; anything can, with the right metadata, be cached (and indeed, I've cached many, many things with the wrong metadata, because of silly site operators and their ideas about "dynamic").
> 
> Now, if people want to target a particular implementation that makes it easier to serve a particular style of URL without writing code, fine, but let's not confuse things.
> 
> E.g., a URL like
> 
> I'm also going to push back on the "it may not be feasible to do that across all organizations and deployments" motivation. This is a race to the bottom. The trick is to make it accessible enough to get sufficient traction to pull everyone along, without pandering to *everyone*'s requirements.
> 
> Regards,
> 
> --

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 28 Aug 2012 23:37:50 -0400

John,

If Google is hosting the domain or any other service provider, wouldn't
there still be an A record for the domain (e.g., packetizer.com)?  I know
there is for virtually every web hosting company I've used.  It seems like
this might just be one more hosted service Google could provide to its
customers, no?

I do not know exactly how this hosted service works, but what's hosted?  I
assume it's just email.  If web, then I see no issue.  If only email, then
the user just needs to have MX records pointing to Google and an A record
pointing to whatever service runs the WebFinger service.

In any case, if they can add a CNAME or MX record, I think we can get them
to add an A record.  I think it would be far more challenging for SMBs to
add a host like webfinger.example.com.  That would still require an A record
and a service provider capable of supporting it.

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2012 3:29 PM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

There are cases where there are hosted domains (Google etc) that may not
have a http host for the domain name used in the users email address.  

There may be merit to having a webfinger.example.com fallback where the
client can't reach the .well-known for the primary host.

I know that some sort of SRV record would be the correct way to do it, but
in the real world SMB don't enter SRV records even if there DNS provider
support them.

John B.

George,

Your pain is understood, but I do not see a way to avoid it.  We could
introduce something in DNS, but that would also present challenges.  No
matter where we "root" the discovery process, there is a potential somebody
could break it.  It could be rooted somewhere other than the root of the
domain (e.g.,  <http://webfinger.example.com> webfinger.example.com), but we
either need to decide in advance of such a location or introduce a way to
discovery the discovery resources.

Paul

Thanks,
George

--
John Panzer / Google
 <mailto:[email-masked]> [email-masked] /
<http://www.abstractioneer.org/> abstractioneer.org / @jpanzer

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham < <mailto:[email-masked]>
[email-masked]> wrote:

E.g., a URL like

 <http://example.com/.well-known/user/bob>
http://example.com/.well-known/user/bob

Regards,

--
Mark Nottingham    <http://www.mnot.net/> http://www.mnot.net/

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

---

From: John Bradley <[email-masked]>
Date: Wed, 29 Aug 2012 10:14:23 -0400

There mite be a A record but that typically goes off to some virtual web hosting company and not the email service provider.

I think I have also heard William say this is a problem for Yahoo.

Google was not able to get people to deploy XRDS for hosted domains.   They came up with a proprietary extension to openID discovery to make hosted google apps domains work with some subset of RP.

The problem is that the company hosting a small businesses website is unlikely to provide the web finger infrastructure and there is no way for the email/openID provider to do it without their cooperation.

Adding a A record rather than a CNAME is generally not a good idea if it can be avoided.   In the event of the provider changing an IP address it breaks all the customers if they have used A records, but that is separate issue.  

You can set up webfinger on your web server and manage it.   It just won't work for large numbers of people as we have it now.  

If webfinger won't work for Google Apps for Domains and other hosted services like that then It will significantly impact adoption in my opinion.

We will also need to work around that for Connect.  We don't want another proprietary work around with the security problems that can entail.

John B.

On 2012-08-28, at 11:37 PM, "Paul E. Jones" <[email-masked]> wrote:

> John,
>  
> If Google is hosting the domain or any other service provider, wouldn’t there still be an A record for the domain (e.g.,packetizer.com)?  I know there is for virtually every web hosting company I’ve used.  It seems like this might just be one more hosted service Google could provide to its customers, no?
>  
> I do not know exactly how this hosted service works, but what’s hosted?  I assume it’s just email.  If web, then I see no issue.  If only email, then the user just needs to have MX records pointing to Google and an A record pointing to whatever service runs the WebFinger service.
>  
> In any case, if they can add a CNAME or MX record, I think we can get them to add an A record.  I think it would be far more challenging for SMBs to add a host like webfinger.example.com.  That would still require an A record and a service provider capable of supporting it.
>  
> Paul
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 29 Aug 2012 11:37:55 -0400

On 8/28/12 3:17 PM, Paul E. Jones wrote:
>
> George,
>
> I believe it might be useful to introduce those who break your 
> WebFinger server to Louisville Slugger. :)
>
:)
> introduce something in DNS, but that would also present challenges.  
> No matter where we "root" the discovery process, there is a potential 
> somebody could break it.  It could be rooted somewhere other than the 
> root of the domain (e.g., webfinger.example.com), but we either need 
> to decide in advance of such a location or introduce a way to 
Well this is one reason I liked XRD and host-meta:) I could put one 
static file on the CDN and get it served up by the right domain. Not so 
difficult.

With Simple Web Discovery, there is support for a "global" redirect so I 
can again add yet another static file to the CDN to point the discovery 
service elsewhere. Not ideal but probably manageable.

However, making the .well-known URLs dynamic makes this more difficult. 
I suppose if I can some how ignore all the "per user" paths or query 
parameters and webfinger supports a global redirect for the domain, I 
can probably use my Louisville Slugger to get it to stick:)

Thanks,
George
>
> Paul
>
> *From:[email-masked] 
> [mailto:[email-masked]] *On Behalf Of *George Fletcher
> *Sent:* Tuesday, August 28, 2012 11:09 AM
> *To:* Mark Nottingham
> *Cc:* IETF Apps Discuss
> *Subject:* Re: [apps-discuss] Looking at Webfinger
>
> Way "late to the party" but I can speak from experience that 
> deployment can be a real issue in some environments. It's all really 
> straight forward in a small company or an environment where the 
> identity team "owns" the root domain (e.g. example.com). However, if 
> an entire other group in a large organization "owns" the root domain 
> (home page for the site) and the identity team then needs to get them 
> to make changes, the deployment solution gets brittle pretty quick. 
> I've had our webfinger support broken at least twice because the 
> "other" team didn't know that certain configs were required:)
>
> Also, installing the "dynamic pluming" can be more problematic is 
> these cases. It is possible to get apache rewrite rules or netscaler 
> magic in place to make it work, it's just a more brittle deployment 
> architecture.
>
> Thanks,
> George
>
>     Mark -- Of course I was speaking about practical realities of
>     typical web server administration and deployment.  In practical
>     terms, adding a new mod_rewrite rule or moral equivalent is going
>     to be easier than adding a new PHP script that connects to a
>     database.  The latter is just always going to be a much higher bar.
>
>     And, something that returns per-user data is generally going to
>     need a dynamic service of some kind, unless your site has just a
>     handful of users and you don't mind going through a publishing
>     exercise each time you add or change a user...
>
>     None of this has anything to do with the interface, just
>     deployment realities.  And in reality all of this is going to need
>     a dynamic service somewhere for each non-trivial site, this is all
>     just a question of how to hook it up.
>
>
>     --
>     John Panzer / Google
>     [email-masked] <mailto:[email-masked]> /
>     abstractioneer.org <http://www.abstractioneer.org/> / @jpanzer
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 Aug 2012 13:36:41 -0400

John,

Well, we need to figure out how to address this.

Would it be reasonable to redirect requests from /.well-known/host-meta.json
and /.well-known/host-meta to Google?

Are there other services or files under /.well-known that Google's customers
would not want Google to host?  If they were OK with Google's servers
responding to anything , then one could put an A (or CNAME) record in place
for example.com that points to Google.

Not being familiar with what Google offers, I'm a bit challenged to
understand exactly what is and is not possible.

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Wednesday, August 29, 2012 10:14 AM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

There mite be a A record but that typically goes off to some virtual web
hosting company and not the email service provider.

Google was not able to get people to deploy XRDS for hosted domains.   They
came up with a proprietary extension to openID discovery to make hosted
google apps domains work with some subset of RP.

The problem is that the company hosting a small businesses website is
unlikely to provide the web finger infrastructure and there is no way for
the email/openID provider to do it without their cooperation.

Adding a A record rather than a CNAME is generally not a good idea if it can
be avoided.   In the event of the provider changing an IP address it breaks
all the customers if they have used A records, but that is separate issue.  

You can set up webfinger on your web server and manage it.   It just won't
work for large numbers of people as we have it now.  

If webfinger won't work for Google Apps for Domains and other hosted
services like that then It will significantly impact adoption in my opinion.

We will also need to work around that for Connect.  We don't want another
proprietary work around with the security problems that can entail.

John B.

John,

If Google is hosting the domain or any other service provider, wouldn't
there still be an A record for the domain (e.g., <http://packetizer.com>
packetizer.com)?  I know there is for virtually every web hosting company
I've used.  It seems like this might just be one more hosted service Google
could provide to its customers, no?

In any case, if they can add a CNAME or MX record, I think we can get them
to add an A record.  I think it would be far more challenging for SMBs to
add a host like  <http://webfinger.example.com> webfinger.example.com.  That
would still require an A record and a service provider capable of supporting
it.

Paul

There may be merit to having a  <http://webfinger.example.com>
webfinger.example.com fallback where the client can't reach the .well-known
for the primary host.

John B.

On 2012-08-28, at 3:17 PM, "Paul E. Jones" < <mailto:[email-masked]>
[email-masked]> wrote:

George,

Paul

From:  <mailto:[email-masked]> [email-masked]
[mailto:apps- <mailto:[email-masked]> [email-masked]] On
Behalf Of George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

domain (e.g.  <http://example.com> example.com). However, if an entire other

Thanks,
George

 

E.g., a URL like

Regards,

---

From: John Bradley <[email-masked]>
Date: Wed, 29 Aug 2012 13:57:34 -0400

I am not the best person to represent Google's needs.

However as I understand it Google hosts applications such as email documents openID for tens of thousands of domains.
Google themselves don't control the DNS.

The people using the service generally add some MX records for aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.

The A record for the bare domain typically points off to some Content management site the company uses for their web pages.

I think this is probably typical of Yahoo's mail hosting services and others.   

The service hosing the email/authentication/openID is not the one that controls the web server for company.

Saying the CMS venders will provide WebFinger services doesn't seem all that likely, especially in virtual hosting environments.

Getting a typical company to do anything more than enter a cname for webfinger.example.org is wildly optimistic.

I am entirely open to Ideas on this.   However the previous solution of having every RP check with google first to see if they host the email and provide the XRDS seems horribly flawed to me.

I would like to see a workable solution at the discovery layer that accommodates how people deploy there sites.

I think Bill suggested at one point using the MX record to find the webfinger host.  That has a bunch of problems I would prefer to avoid.

John B.

On 2012-08-29, at 1:36 PM, "Paul E. Jones" <[email-masked]> wrote:

> Would it be reasonable to redirect requests from /.well-known/host-meta.json and /.well-known/host-meta to Google?
>  
> Are there other services or files under /.well-known that Google’s customers would not want Google to host?  If they were OK with Google’s servers responding to anything , then one could put an A (or CNAME) record in place for example.com that points to Google.
>  
> Not being familiar with what Google offers, I’m a bit challenged to understand exactly what is and is not possible.
>  
> Paul
>

---

From: John Panzer <[email-masked]>
Date: Wed, 29 Aug 2012 11:13:06 -0700

Based on experience, I'd prefer to avoid things that depend on the bare
("naked") domain (example.com instead of www.example.com or
webfinger.example.com).  I could write up the reasons but it'd take some
time.  Unfortunately, webfinger as originally spec'd requires this.

If we were to start over, and get to vote for whatever I wanted, and were
going to allow DNS records at all, I would probably vote for something like
webfinger.example.com as a special magic name (with the actual name chosen
so as not to collide with any existing DNS entries).  Any normal hosting
mechanisms will work here, including A records and CNAMEs and HTTP
redirects, but I'd also require everything be done via TLS with correctly
signed certificates for that subdomain (argh!  the pain!).

Organizationally, this would mean that any part of the organization that
can stand up a separate SSL service on a new subdomain can provide
webfinger services.

On Wed, Aug 29, 2012 at 10:57 AM, John Bradley <[email-masked]> wrote:

> However as I understand it Google hosts applications such as email
> documents openID for tens of thousands of domains.
> The people using the service generally add some MX records for
> aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.
>
> The A record for the bare domain typically points off to some Content
> management site the company uses for their web pages.
>
> Saying the CMS venders will provide WebFinger services doesn't seem all
> that likely, especially in virtual hosting environments.
>
> Getting a typical company to do anything more than enter a cname for
> webfinger.example.org is wildly optimistic.
>
> I am entirely open to Ideas on this.   However the previous solution of
> having every RP check with google first to see if they host the email and
> provide the XRDS seems horribly flawed to me.
>
> I would like to see a workable solution at the discovery layer that
> accommodates how people deploy there sites.
>
> I think Bill suggested at one point using the MX record to find the
> webfinger host.  That has a bunch of problems I would prefer to avoid.
>
> John B.
>
> John,****
> Well, we need to figure out how to address this.****
>
> Would it be reasonable to redirect requests from
> /.well-known/host-meta.json and /.well-known/host-meta to Google?****
>
> Are there other services or files under /.well-known that Google’s
> customers would not want Google to host?  If they were OK with Google’s
> servers responding to anything , then one could put an A (or CNAME) record
> in place for example.com that points to Google.****
>
> Not being familiar with what Google offers, I’m a bit challenged to
> understand exactly what is and is not possible.****
>
> Paul****
>
>  *From:* John Bradley [mailto:[email-masked]]
> *Sent:* Wednesday, August 29, 2012 10:14 AM
> *To:* Paul E. Jones
> *Cc:* 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> *Subject:* Re: [apps-discuss] Looking at Webfinger****
> ** **
> hosting company and not the email service provider.****
> ** **
> I think I have also heard William say this is a problem for Yahoo.****
> ** **
> Google was not able to get people to deploy XRDS for hosted domains.
> They came up with a proprietary extension to openID discovery to make
> hosted google apps domains work with some subset of RP.****
> ** **
> the email/openID provider to do it without their cooperation.****
> ** **
> Adding a A record rather than a CNAME is generally not a good idea if it
> can be avoided.   In the event of the provider changing an IP address it
> breaks all the customers if they have used A records, but that is separate
> issue.  ****
> ** **
> work for large numbers of people as we have it now.  ****
> ** **
> ****
> ** **
> proprietary work around with the security problems that can entail.****
> ** **
> John B.****
> ** **
> ****
> ****
> John,****
>  ****
> If Google is hosting the domain or any other service provider, wouldn’t
> there still be an A record for the domain (e.g.,packetizer.com)?  I know
> there is for virtually every web hosting company I’ve used.  It seems like
> customers, no?****
>  ****
> I do not know exactly how this hosted service works, but what’s hosted?  I
> assume it’s just email.  If web, then I see no issue.  If only email, then
> pointing to whatever service runs the WebFinger service.****
>  ****
> add a host like webfinger.example.com.  That would still require an A
> record and a service provider capable of supporting it.****
>  ****
> Paul****
>  ****
> *From:* John Bradley [mailto:[email-masked]]
> *Sent:* Tuesday, August 28, 2012 3:29 PM
> *To:* Paul E. Jones
> *Cc:* 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> *Subject:* Re: [apps-discuss] Looking at Webfinger****
>  ****
> have a http host for the domain name used in the users email address.  ***
> *
>  ****
> client can't reach the .well-known for the primary host.****
>  ****
> support them.****
> The most you can get them to do is add a CNAME or MX record.****
>  ****
> Supporting these sorts of domains somehow is a important issue.****
>  ****
> John B.****
>  ****
> On 2012-08-28, at 3:17 PM, "Paul E. Jones" <[email-masked]> wrote:*
> ***
>
>
>
> ****
> George,****
>  ****
> server to Louisville Slugger. :)****
>  ****
> matter where we “root” the discovery process, there is a potential somebody
> resources.****
>  ****
> Do you have a suggestion that would make this less likely to be broken?***
> *
>  ****
> Paul****
>  ****
> *From:* [email-masked] [mailto:apps-
> [email-masked]] *On Behalf Of *George Fletcher
> *Subject:* Re: [apps-discuss] Looking at Webfinger****
>  ****
>
> can be a real issue in some environments. It's all really straight forward
> in a small company or an environment where the identity team "owns" the
> root domain (e.g. example.com). However, if an entire other group in a
> large organization "owns" the root domain (home page for the site) and the
> solution gets brittle pretty quick. I've had our webfinger support broken
> at least twice because the "other" team didn't know that certain configs
> were required:)
>
> George****
> On 7/4/12 6:58 PM, John Panzer wrote:****
>
> mod_rewrite rule or moral equivalent is going to be easier than adding a
> new PHP script that connects to a database.  The latter is just always
> going to be a much higher bar.****
>  ****
> change a user...****
>  ****
> hook it up.****
> ****
> @jpanzer****
>  ****
>  ****
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <[email-masked]> wrote:****
>
> API at a particular /.well-known endpoint (because it may not be feasible
> to do that across all organizations and deployments).  The host-meta
> document itself would be highly cacheable and so wouldn't incur an
> additional network trip in the common case.
> >
> service behind well-known...****
> I'm also going to push back on the "it may not be feasible to do that
> across all organizations and deployments" motivation. This is a race to the
> bottom. The trick is to make it accessible enough to get sufficient
> traction to pull everyone along, without pandering to *everyone*'s
> requirements.
>
> Regards,****
>
>
> --
> ****
>  ****
> ****
> _______________________________________________****
>
>
> apps-discuss mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>  ****
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>
>

---

From: William Mills <[email-masked]>
Date: Wed, 29 Aug 2012 11:25:24 -0700 (PDT)

Actually my suggestion of using MX records actually was forwarded to the list from a conversation with Breno from Google as I remember, as a more workable but definitely not ideal solution.

>________________________________
> From: John Bradley <[email-masked]>
>To: Paul E. Jones <[email-masked]> 
>Cc: Mark Nottingham <[email-masked]>; IETF Apps Discuss <[email-masked]> 
>Sent: Wednesday, August 29, 2012 10:57 AM

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 Aug 2012 16:44:07 -0400

Guys,

John, I understand the pain of getting TLS records properly installed.  It's
no small task, for sure.  I am hoping DNSSEC and RFC 6698 might help with
this.  That sounds scary, but it's really fairly simple to configure.  Most
importantly, it can be easily automated.  I can't very well automate telling
somebody to go to a CA and buy a certificate . wait, first generate a CSR
and then. it's messy.  But, it's presently a necessary evil.

What I am hearing is that we must allow the host-meta{.json} resource to be
relocated.  That relocation could be via HTTP redirects (already mandatory)
or something else.  The only other mechanisms that seem extremely trivial to
me are:

1) TXT records (e.g., _webfinger.packetizer.com IN TXT
"https://packetizer.webfinger-provider.com/")

2) A records (e.g., webfinger.packetizer.com IN A 10.1.2.3)

3) CNAME records (e.g., webfinger.packetizer.com IN CNAME
packetizer.webfinger-provider.com.)

I'm not a fan of any of those, but querying "webfinger.packetizer.com" seems
like it would be the easiest alternative (meaning one could use either A or
CNAME records).

So, the client would issue these queries in this order

1)      https://packetizer.com/.well-known/host-meta.json

2)      https://webfinger.packetizer.com/.well-known/host-meta.json

3)      http://packetizer.com/.well-known/host-meta.json

4)      http://webfinger.packetizer.com/.well-known/host-meta.json

Note the ordering to ensure that TLS is attempted before insecure
connections.

Is this something we really need to do?  If so, it also suggests that other
services rooted in /.well-known are going to present similar issues.

Paul

From: John Panzer [mailto:[email-masked]] 
Sent: Wednesday, August 29, 2012 2:13 PM
To: John Bradley
Cc: Paul E. Jones; Mark Nottingham; IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

Organizationally, this would mean that any part of the organization that can
stand up a separate SSL service on a new subdomain can provide webfinger
services.  

However as I understand it Google hosts applications such as email documents
openID for tens of thousands of domains.

I think this is probably typical of Yahoo's mail hosting services and
others.   

The service hosing the email/authentication/openID is not the one that
controls the web server for company.

Saying the CMS venders will provide WebFinger services doesn't seem all that
likely, especially in virtual hosting environments.

John B.

John,

Are there other services or files under /.well-known that Google's customers
would not want Google to host?  If they were OK with Google's servers
responding to anything , then one could put an A (or CNAME) record in place
for  <http://example.com> example.com that points to Google.

Paul

John B.

On 2012-08-28, at 11:37 PM, "Paul E. Jones" < <mailto:[email-masked]>
[email-masked]> wrote:

John,

Paul

From: John Bradley [mailto:ve7jtb@ <http://ve7jtb.com> ve7jtb.com] 
Sent: Tuesday, August 28, 2012 3:29 PM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

John B.

George,

Paul

Thanks,
George

 

E.g., a URL like

Regards,

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 30 Aug 2012 05:01:59 +0200

On 29 aug 2012, at 22:44, Paul E. Jones <[email-masked]> wrote:

> 1) TXT records (e.g., _webfinger.packetizer.com IN TXT “https://packetizer.webfinger-provider.com/”)

Please see URI Resource Record, for example:

_webfinger._tcp.packetizer.com. IN URI 0 0 “https://packetizer.webfinger-provider.com/”

   Patrik

---

From: William Mills <[email-masked]>
Date: Wed, 29 Aug 2012 23:03:07 -0700 (PDT)

There are a few folks that feel that SRV records are not really an option for hosting situatiosn where the users don't currently have the ability to configure SRV records.

> From: Patrik Fältström <[email-masked]>
>Cc: 'Mark Nottingham' <[email-masked]>; 'IETF Apps Discuss' <[email-masked]> 
>Sent: Wednesday, August 29, 2012 8:01 PM

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 30 Aug 2012 08:44:52 +0200

First, I did not talk about SRV records, but URI records.

Secondly, I think it is fascinating that people that love new things like "the web" and new HTML5 features are the most conservative ones regarding other protocols like DNS.

With that attitude, we have no evolution, and no innovation.

Providers that do not support such features will die. It is that simple.

   Patrik

---

From: John Bradley <[email-masked]>
Date: Thu, 30 Aug 2012 17:00:34 -0400

I agree that doing it via DNS would be the proper way.

The reality is that not all clients can easily access DNS directly.  Doing anything more than a http get reduces adoption.

Not all DNS providers support srv records.  I think your draft on DNS records has expired, and I know of no support for it.
http://tools.ietf.org/html/draft-faltstrom-uri-06

Something like DNS records would be the answer, I just don't think protocols like Webfinger are likely to wait for wide deployment of that as a underlying technology.

John B.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 30 Aug 2012 23:41:01 +0200

On 30 aug 2012, at 23:00, John Bradley <[email-masked]> wrote:

> The reality is that not all clients can easily access DNS directly.

Give examples please.

   Patrik

---

From: James M Snell <[email-masked]>
Date: Fri, 31 Aug 2012 10:33:15 -0700

One of the key problems with all of this is that it really does not account
for the fundamental use case of WebFinger: discovering which services and
data are available for a given user within a given domain. Google, for
instance, may host the email, but the users blog, calendar, or other
services may have nothing to do with google. In fact, Google may not know
*anything* about domains users and would therefore be generally incapable
of providing useful information. In order for WebFinger to be useful, even
with a DNS based bootstrap, the domain owner is going to have to provide
the information about its users.

If the domain owner wishes to provide webfinger services, but defer that
back to a google hosted service, the domain host should manage
/.well-known/* itself and provide a reasonable http redirect back to the
google hosted service. Then, the domain owner would need to work with
google to ensure that the information served up is useful (even then,
however, it would likely be just as easy for the domain owner to host
everything themselves).

Referring back to my index draft [1].. it could look something like...

 GET /.well-known/index/\
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
 calendar
Host: example.org

HTTP/1.1 302 Found
 Location: https://webfinger.google.com/example.org/\
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
 calendar

[1] http://www.ietf.org/id/draft-snell-web-index-00.txt

- James

---

From: John Bradley <[email-masked]>
Date: Fri, 31 Aug 2012 13:49:53 -0400

If the bar is to high for people deploying or delegating Webfinger then protocols like OpenID Connect will need to find another alternative for the discovery of IdP information about a user.

My point is that managing a /.well-known/* is beyond the ability of many people.

John B.

On 2012-08-31, at 1:33 PM, James M Snell <[email-masked]> wrote:

> One of the key problems with all of this is that it really does not account for the fundamental use case of WebFinger: discovering which services and data are available for a given user within a given domain. Google, for instance, may host the email, but the users blog, calendar, or other services may have nothing to do with google. In fact, Google may not know *anything* about domains users and would therefore be generally incapable of providing useful information. In order for WebFinger to be useful, even with a DNS based bootstrap, the domain owner is going to have to provide the information about its users.
> 
> If the domain owner wishes to provide webfinger services, but defer that back to a google hosted service, the domain host should manage /.well-known/* itself and provide a reasonable http redirect back to the google hosted service. Then, the domain owner would need to work with google to ensure that the information served up is useful (even then, however, it would likely be just as easy for the domain owner to host everything themselves).
>

---

From: Bob Wyman <[email-masked]>
Date: Fri, 31 Aug 2012 16:35:41 -0400

On Fri, Aug 31, 2012 at 1:33 PM, James M Snell <[email-masked]> wrote:

> One of the key problems with all of this is that it really does not
> account for the fundamental use case of WebFinger: discovering which
> services and data are available for a given user within a given domain.

I agree with your definition of the "fundamental use case for WebFinger"
only until you write "within a given domain." Including that seemingly
minor flourish at the end of the definition drastically changes what *i*
think is the fundamental use case for WebFinger.

The "within a given domain" seems to imply that any domain that provides
service to a user would be able to acknowledge that fact and perhaps
provide, in response to queries, some information about the user. Thus,
your definition seems to cast WebFinger as a tool to enable services to
talk about their users.

But, I view the value and use of WebFinger very differently. To me
WebFinger isn't something that allows services to talk about users, but
rather a tool to enable users to usefully describe themselves and the
services that can or should be used to interact with them.

I might use dozens of services, but I expect that only one of those
services, my chosen WebFinger provider, would ever provide any metadata
concerning me. The only exception to this is that I may chose to allow some
or all of the non-WebFinger services that I use to provide a link to my
chosen WebFinger service -- by providing an acct: URI that I have provided.

You say: "In order for WebFinger to be useful,... the domain owner is going
to have to provide the information about its users." I don't think this is
right. I suggest that "In order for WebFinger to be useful, then
*users*are going to have to provide WebFinger with information about
themselves.

I may choose to use "gmail.com" as my email provider. However, even if I
do, I should be free to use "example.com" to host my WebFinger acct: URI.
Simply because you have discovered my email address shouldn't allow you to
discover my acct: URI, or anything else about me, unless I've explicitly
chosen to allow that. Also, I shouldn't be required to receive *any*
service other than WebFinger from my WebFinger provider. (In fact, I can
see that being a WebFinger provider would make a nice business for some
folk.) What this means is that if some email provider has things set up so
that I can't use them as a WebFinger host, I'm simply going to get that
service from somewhere else. I'll then identify myself to people using my
acct: URI and will switch my email account around based on who gives me the
best service today. I won't be pinned to an email service simply because
some people think it is part of my "name." (Note: Email providers would be
well advised to provide good WebFinger services if they wish to remain
competitive.)

Given the above, it makes sense to me that the simplest implementation of
WebFinger should require no more of me other than creating an XML or JSON
encoded file (I don't care which) and causing that file to appear in some
known, HTTP-accessible, location on the web. If one or more of the services
I currently use can't or won't allow that, then too bad for them. I'll host
my WebFinger data somewhere else.

In summary: WebFinger is supposed to be about users providing information
about themselves, not about services providing information about their
users.

bob wyman

Google, for instance, may host the email, but the users blog, calendar, or
> other services may have nothing to do with google. In fact, Google may not
> know *anything* about domains users and would therefore be generally
> incapable of providing useful information. In order for WebFinger to be
> useful, even with a DNS based bootstrap, the domain owner is going to have
> to provide the information about its users.
>
>> You can set up webfinger on your web server and manage it.   It just
>> won't work for large numbers of people as we have it now.  ****
>> ** **
>> On 2012-08-28, at 11:37 PM, "Paul E. Jones" <[email-masked]>
>> wrote:****
>>
>>
>> ****
>> John,****
>>  ****
>> I do not know exactly how this hosted service works, but what’s hosted?
>> I assume it’s just email.  If web, then I see no issue.  If only email,
>> then the user just needs to have MX records pointing to Google and an A
>> record pointing to whatever service runs the WebFinger service.****
>>  ****
>> In any case, if they can add a CNAME or MX record, I think we can get
>> them to add an A record.  I think it would be far more challenging for SMBs
>> to add a host like webfinger.example.com.  That would still require an A
>> have a http host for the domain name used in the users email address.  **
>> **
>>  ****
>> I know that some sort of SRV record would be the correct way to do it,
>> but in the real world SMB don't enter SRV records even if there DNS
>> provider support them.****
>> Do you have a suggestion that would make this less likely to be broken?**
>> **
>>  ****
>> Paul****
>>  ****

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 31 Aug 2012 21:49:50 -0400

James,

If Google were hosting the domain and wanted to populate WF without the domain owner having any input into the contents, you’re entirely right.

However, if we step back and look at what RFC 6415 defines with the LRDD type, this is possible.  Then the domain owner might just be able to have a static file that contained things like this:

     <Link rel='lrdd'

      type='application/xrd+xml'

      template='http://webfinger.google.com/lrdd?uri={uri}' />

     <Link rel='lrdd'

      type='application/xrd+xml'

      template='http://webfinger.anotherprovider.com/lrdd?uri={uri}' />

When utilizing the “resource” parameter, the expectation is that the software running on the domain would query Google and “anotherprovider” and then merge the resulting set of link relations and return that to the client.

This would address the issue where Google provides some services and other companies provide other services.

The domain owner could outsource all of this to a third party using either a 302 or, as Patrik suggested, using a URI DNS record.  I like the URI resource record idea, as that would address issues where the domain owner cannot provide any services from .well-known, even a 302 redirect.  (That said, it amazes me that one could not do return a 302.  There really are such domain owners?)

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Friday, August 31, 2012 1:33 PM
To: John Bradley
Cc: Paul E. Jones; Mark Nottingham; IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

GET /.well-known/index/\

calendar

Host: example.org

HTTP/1.1 302 Found

Location: https://webfinger.google.com/example.org/\ <https://webfinger.google.com/example.org/> 

calendar

- James

John B.

John,

Are there other services or files under /.well-known that Google’s customers would not want Google to host?  If they were OK with Google’s servers responding to anything , then one could put an A (or CNAME) record in place for  <http://example.com> example.com that points to Google.

Paul

John B.

On 2012-08-28, at 11:37 PM, "Paul E. Jones" < <mailto:[email-masked]> [email-masked]> wrote:

John,

If Google is hosting the domain or any other service provider, wouldn’t there still be an A record for the domain (e.g., <http://packetizer.com> packetizer.com)?  I know there is for virtually every web hosting company I’ve used.  It seems like this might just be one more hosted service Google could provide to its customers, no?

In any case, if they can add a CNAME or MX record, I think we can get them to add an A record.  I think it would be far more challenging for SMBs to add a host like  <http://webfinger.example.com> webfinger.example.com.  That would still require an A record and a service provider capable of supporting it.

Paul

There may be merit to having a  <http://webfinger.example.com> webfinger.example.com fallback where the client can't reach the .well-known for the primary host.

John B.

On 2012-08-28, at 3:17 PM, "Paul E. Jones" < <mailto:[email-masked]> [email-masked]> wrote:

George,

Your pain is understood, but I do not see a way to avoid it.  We could introduce something in DNS, but that would also present challenges.  No matter where we “root” the discovery process, there is a potential somebody could break it.  It could be rooted somewhere other than the root of the domain (e.g.,  <http://webfinger.example.com> webfinger.example.com), but we either need to decide in advance of such a location or introduce a way to discovery the discovery resources.

Paul

From:  <mailto:[email-masked]> [email-masked] [mailto:apps- <mailto:[email-masked]> [email-masked]] On Behalf Of George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

Way "late to the party" but I can speak from experience that deployment can be a real issue in some environments. It's all really straight forward in a small company or an environment where the identity team "owns" the root domain (e.g.  <http://example.com> example.com). However, if an entire other group in a large organization "owns" the root domain (home page for the site) and the identity team then needs to get them to make changes, the deployment solution gets brittle pretty quick. I've had our webfinger support broken at least twice because the "other" team didn't know that certain configs were required:)

Thanks,
George

--
John Panzer / Google
 <mailto:[email-masked]> [email-masked] /  <http://www.abstractioneer.org/> abstractioneer.org / @jpanzer

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham < <mailto:[email-masked]> [email-masked]> wrote:

E.g., a URL like

 <http://example.com/.well-known/user/bob> http://example.com/.well-known/user/bob

Regards,

 

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

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

---

From: John Bradley <[email-masked]>
Date: Fri, 31 Aug 2012 22:11:33 -0400

John Panzer can probably give a more specific answer. 

My understanding is that there are thousands of hosted domains for email that have a low probability of doing a 302 redirect. 

I am saying that a simple DNS mechanism for locating the web finger host would improve flexibility and increase deployments. 

Sent from my iPhone

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 1 Sep 2012 12:19:08 +0900

I think it is not the problem of the clients. Any decent scripting
language has the ability to query SRV records in DNS.

It is the problem of the DNS service provider, which always have GUI
for A and CNAME records but not necessarily TXT or SRV records.

Having said that, have we done the reality check on the above claim
that those providers do not support them? Quick check reveals the
following about top domain registrar's support SRV records (market
share is from http://collegefallout.com/list-of-top-10-domain-name-registrars/
which may not be correct) :

- Regstrar Name (market share) Support of SRV record

- GoDaddy (31%)YES
- enom.com (8.5%) YES
- TuCows (6.6%) ???
- NetworkSolutions (5.4%) YES
- Schlund+Partner (4.3%) NO
- melbourneit (3.6%) NO
- Wild West Domains (2.8%) YES
- moniker.com (2.4%) ???
- ResellerClub (2.2%) YES
- REGISTER.com (2.0%) YES

It is actually better than I thought. The world may be changing...

Nat

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en