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

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 11 Sep 2012 00:06:28 -0400

John,

I've hosted my domains with the smallest providers and I manage my primary
domain myself.  In all cases, I've been able to use 3xx to redirect
requests.  Do you think this will not be workable for any domain owners?

I agree that if we had to do it all over again, we could explore lots of
options.  I do like the idea of a URI DNS record, but I'm not sure if any
clients would query for it even if we mandated it at this point.

We could specify a special name like "_webfinger.example.com".  However, we
run into the same issues: clients may not query for that.  Perhaps equally
important, this shifts us away from the ".well-known" work that was defined.

What we do not want, of course, is a solution that is DOA.  If there is
anything about WF that is going to halt adoption, let's fix it now.
Otherwise, I suggest we live with what has been specified.

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

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:

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:

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  <http://example.com> 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.

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" < <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?

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  <http://webfinger.example.com> webfinger.example.com.  That
would still require an A record and a service provider capable of supporting
it.

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

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  <http://webfinger.example.com>
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" < <mailto:[email-masked]>
[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.,  <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.

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

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:)

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
 <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:

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>
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/> 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

_______________________________________________
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
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John Bradley <[email-masked]>
Date: Tue, 11 Sep 2012 12:45:05 -0300

Having a webfinger host doesn't necessarily move us away from .well-known.

I am not attached to any particular solution.  

For openID Connect we must be able to support google apps domains and others.
For that the admins of those domains need to be able to perform the configuration.   A solution that only works for an expert will fail.

It also needs appropriate security considerations.

One concern is if discovery is not done securely it creates a phishing opportunity.

If I can change someones discovery record I can have a RP redirect them to a fake IdP and phish there credentials.
Other protocols wishing to use webfinger may have similar concerns.  That is why SWD is https: only.

DNS without DNSsec is not without issues.

It would be attractive to use a SRV record to get the host and port for making the TLS request though for security reasons the domain would need to match in some way unless you are doing DNSsec. 
This seems like it may be too complicated to work well.

I agree that redirecting at the HTTP level using https: URI would work if domains can deploy them.  
The question to Google and others who have done the research is what can domain owners reasonably be expected to do.

John B.

On 2012-09-11, at 1:06 AM, "Paul E. Jones" <[email-masked]> wrote:

> John,
>  
> I’ve hosted my domains with the smallest providers and I manage my primary domain myself.  In all cases, I’ve been able to use 3xx to redirect requests.  Do you think this will not be workable for any domain owners?
>  
> I agree that if we had to do it all over again, we could explore lots of options.  I do like the idea of a URI DNS record, but I’m not sure if any clients would query for it even if we mandated it at this point.
>  
> We could specify a special name like “_webfinger.example.com”.  However, we run into the same issues: clients may not query for that.  Perhaps equally important, this shifts us away from the “.well-known” work that was defined.
>  
> What we do not want, of course, is a solution that is DOA.  If there is anything about WF that is going to halt adoption, let’s fix it now.  Otherwise, I suggest we live with what has been specified.
>  
> Paul
>  
> Based on experience, I'd prefer to avoid things that depend on the bare ("naked") domain (example.com instead ofwww.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.  
> 
> 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.comto 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.
>  
> 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
>  
> 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.
>  
> 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
>  
> 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.
> 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
>  
>  
> 
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <[email-masked]> 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,
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
>  
> 
> 
> 
> 
>

---

From: John Bradley <[email-masked]>
Date: Tue, 11 Sep 2012 12:49:22 -0300

Nat,

TuCows supports SRV records at least for openSRS.   Some of there resellers may be using other things to manage DNS recodes and just using them for registration, so it would be hard to make a blanket statement.

I think using a SRV record introduces other security issues that would have to be looked at without DNSsec.

John B.

On 2012-08-31, at 11:19 PM, Nat Sakimura <[email-masked]> wrote:

> 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
> 
> 
> On Fri, Aug 31, 2012 at 6:00 AM, John Bradley <[email-masked]> wrote:
>> 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.
>> On 2012-08-30, at 2:44 AM, Patrik Fältström <[email-masked]> wrote:
>> 
>>> 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
>>> 
>>> On 30 aug 2012, at 08:03, William Mills <[email-masked]> wrote:
>>> 
>>>> 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]>
>>>> To: Paul E. Jones <[email-masked]>
>>>> Cc: 'Mark Nottingham' <[email-masked]>; 'IETF Apps Discuss' <[email-masked]>
>>>> Sent: Wednesday, August 29, 2012 8:01 PM
>>>> 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
>>>> 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 25 Sep 2012 01:34:17 -0400

> I think using a SRV record introduces other security issues that would have to be looked at without DNSsec.

I think this is true regardless. DNSSEC should be a top priority for 
anyone, really.  Otherwise, there exists the risk of having the domain 
requests hijacked.  And if one can do that, they can probably get 
certificates for the hijacked domains.

Paul