Re: [Aggsrv] updated charter proposal

["Paul E. Jones" <[e-mail]>]

Cyrus,

> -----Original Message-----
> From: Cyrus Daboo [mailto:[e-mail]]
> Sent: Wednesday, February 27, 2013 11:10 AM
> To: Paul E. Jones; 'Peter Saint-Andre'; [e-mail]
> Subject: Re: [Aggsrv] updated charter proposal
> 
> Hi Paul,
> 
> --On February 25, 2013 at 5:58:44 PM -0500 "Paul E. Jones"
> <[e-mail]> wrote:
> 
> > I'm confused.  How is what is being described different than what
> > WebFinger can do? From what I can tell, what is missing is just the
> > definition of "rel" and "properties" values for WebFinger.  That would
> > be a good focus for the group.
> >
> > Do we want to define another new protocol that is so similar?
> 
> Will you be in Orlando to provide input to the BoF?

Yeah, I will be there.
 
> It does look like webfinger could be a viable solution - and indeed I
> see you have an example in the webfinger spec of auto-configuration of
> an email client. Maybe it is sufficient for aggsrv to standardize the
> appropriate properties for services, and semantics of priority, grouping,
> and security requirements.

Yeah, but it's only for illustrative purposes.  It is there more to
demonstrate the use of "properties" in WebFinger than to prescribe a
solution to mail server auto-provisioning.

> What I might do is try taking the examples in the spec I wrote and see
> what they would look like in terms of webfinger.

Cool.  If you need any input, I'm glad to provide it.
 
> That said, I have some questions:
> 
> 1) Security - it still seems to me that there is a fundamental
> difference in security "contexts" here. In particular, the aggsrv
> information must only be given out to the actual "owner" of the account.
> The webfinger spec does have a section on access control, aggsrv would
> need to have much stronger language. At the very least I think you
> should change Section 3.3 of webfinger to include an example of an
> authenticated HTTP request and point out in the text that authentication
> is required.

It's mentioned in the WebFinger spec (or is supposed to be) that linked
resources might require their own authentication.  For mail server
configuration, for example, I can fully appreciate that one might use a TLS
connection to some other URI and use basic authentication with the user's
email server user ID and password for authentication.  The response might be
some JSON object that contains all of the config data.

> 2) If no rel= parameter is provided in the URI, is the webfinger server
> required to return all information for the target resource= value? It
> seems to me that aggsrv information should not be returned by "default"
> (i.e., when there is no rel=) but rather should only be returned by an
> explicit request for it (with a very specific rel=).

Yeah, without "rel" everything is to be returned.  WebFinger is about
discovery what's published, not just for asking for a specific piece of
information.  If there is a specific piece of information a client is
seeking (such as the case with OpenID Connect), then one can include "rel"
to reduce the size of the response.  Usually, though, one might use a client
(e.g., an email client) and want to discover all kinds of information about
the sender of a message.  So, if I publish my blog URI, H.323 URI, Twitter
ID, etc. you might want to be able to see all of those when you move the
mouse over my name.

Here's an example: http://silverbucket.github.com/avatar.js/

This script queries a WebFinger server and then shows what it finds.
 
> 3) Links - one of the things we want to avoid is having aggsrv clients
> having to follow lots of links to get all the relevant data - that would
> pretty much eliminate one of the key performance enhancements we are
> looking to get with the new protocol over current best practice.

In the above demo, a single query is made to the server and all data is
returned in a single response.  The links can be followed by the user.  If
you want to hide certain information (such as the hostname of the mail
server or whatever), then that would have to be protected behind a link that
requires authentication.

There's a balance that has to be struck here between discovery and
performance of the discovery process AND querying for specific information
that needs to be secured.

> 4) One of the simplest aspects of aggsrv is that it is trivial to setup
> a "static" document with service information and deploy that on the
> well-known URI. That significantly lowers the barrier to entry and makes
> the likelihood of deployment much greater. I am not sure that level of
> simplicity could be achieved with webfinger - at the very least it looks
> like the JRD response has to contain the "subject" member which echoes
> the resource= value. Whilst that could trivially be accomplished by, for
> example, string substitution in a PHP script it does imply additional
> overhead to deploy.

This was something we debated at length working on WebFinger.  There is
certainly an advantage in having a static file for small sites.  On the
other hand, using "rel" is useful and any large service provider I would
expect to pull all raw data from somewhere (e.g., a database), since
generation and maintenance of static files also involves some work.
Regardless, flexibility is there.

Look near the bottom of this page: http://www.packetizer.com/webfinger/
You will see a link to setting up a WF server:
http://www.packetizer.com/webfinger/server.html

This is a WF server implementation I wrote in Perl that I use for my own
server.  It actually does WF and RFC 6415 (XML + JSON) and pulls data from a
MySQL database, so perhaps a good of example of the most complex
implementation.  I don't worry about that, though, as anyone setting up a
server will not be counting lines of code.  One has the option to use a WF
server that uses a scripting language (Perl, PHP, etc.) or Apache re-write
rules that use static files.  I would guess that covers most people who
might want to run their own server.  Those who do not want to run their own
server could redirect requests to a WF "service provider".  That's also an
option.

Paul