Re: [Aggsrv] updated charter proposal

[Cyrus Daboo <[e-mail]>]

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?

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.

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.

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.

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=).

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.

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.

-- 
Cyrus Daboo