Re: [apps-discuss] Looking at Webfinger

[George Fletcher <[e-mail]>]

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. :)
>
:)
>
> 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?
>
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:*[e-mail] 
> [mailto:[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] <mailto:[e-mail]> /
>     abstractioneer.org <http://www.abstractioneer.org/> / @jpanzer
>
>     On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <[e-mail]
>     <mailto:[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]  <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/apps-discuss
>