Re: [apps-discuss] Looking at Webfinger

[Bob Wyman <[e-mail]>]

On Fri, Aug 31, 2012 at 1:33 PM, James M Snell <[e-mail]> 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.
>
> 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
>
> On Wed, Aug 29, 2012 at 10:57 AM, John Bradley <[e-mail]> 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" <[e-mail]> 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 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:[e-mail]]
>> *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" <[e-mail]>
>> 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:* John Bradley [mailto:[e-mail]]
>> *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.****
>> 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" <[e-mail]> 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.****
>>  ****
>> Do you have a suggestion that would make this less likely to be broken?**
>> **
>>  ****
>> Paul****
>>  ****
>> *From:* [e-mail] [mailto:apps-
>> [e-mail]] *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****
>> 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
>> [e-mail] / abstractioneer.org <http://www.abstractioneer.org/> /
>> @jpanzer****
>>  ****
>>
>>  ****
>> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <[e-mail]> 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****
>>
>> [e-mail]****
>>
>> https://www.ietf.org/mailman/listinfo/apps-discuss****
>>
>>  ****
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss****
>>
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>