Subject: [Aggsrv] updated charter proposal

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 22 Feb 2013 11:44:43 -0700

The proponents have sent me an updated charter for the aggsrv
initiative. The text can be found below, and I've also updated
http://trac.tools.ietf.org/wg/appsawg/trac/wiki/AggSrv accordingly.

###

Aggregated Service Discovery Working Group

Problem Statement:

Service providers and enterprises commonly offer a variety of
application services delivered over multiple protocols.  A user will
often consume these services from several endpoints, requiring service
discovery or manual configuration for each service at each endpoint.
Some of these services leverage existing standards-based discovery,
such as DNS, DHCP, or UDDI, while others may rely on some form of
proprietary discovery.  Still others may not support any form of
discovery, requiring the manual entry of service access information.
As the quantity and variety of these services grow, it becomes
increasingly onerous for administrators to manage the disparate
discovery mechanisms, and burdensome on users to provide configuration
where discovery is not supported.

It is useful to first consider whether the issues described here might
be addressable through the direct use or extension of existing
discovery protocols.  DHCP [1], for example, is widely deployed and
supports extension for the discovery of new types of services.  Many
DHCP extensions already exist for the discovery of such services as
DNS, NTP, NIS, LDAP, and others.  The DHCP protocol, however, is
limited by a dependence on local network broadcast, lack of support
for structured data, and an extension mechanism not intended for
unregistered customization.  This, coupled with a relative dearth of
application-level APIs supporting DHCP service-specific extensions,
makes DHCP an unlikely solution for the issues we face here.

Another option would be to leverage DNS through DNS-SD [2].  The DNS-SD
extension is expressly designed to support Internet-scale service
discovery using standard DNS queries and existing record types.
However, it remains a significant limitation that the discovered data
is global and cannot be made a function of information provided in the
request.  For example, an enterprise with several IMAP servers, each
servicing the same email domain but hosting different subsets of
employees, could not employ DNS-SD for email service discovery using
that one domain.  It is also important to consider that we wish to
establish a solution that is broadly and uniformly usable across a
wide array of platforms and environments.  It is an unfortunate fact
that browser-based clients often lack the necessary APIs and trust
necessary to make explicit DNS queries for particular types of records.

In terms of new ideas, similar discovery standardization efforts
already under way include WebFinger [3], which is intended to address
generalized discovery for any type of URI identifiable resource, and
Simple Web Discovery [4], which is more specifically related to the
discovery of services.  The former provides an interesting framework
within which aggregated service discovery could operate, however by
itself there is insufficient guidance and structure to address the
specific needs of service discovery use cases.  Simple Web Discovery,
on the other hand, while expressly intended for the discovery of
services, tends to focus specifically on service location and is not
well suited for aggregate discovery of dissimilar service types.

Objectives:

The Aggregated Service Discovery working group will standardize an
extensible protocol supporting the discovery of multiple services with
a single operation and with limited initial information (e.g. a
well-known URL, or email address).  A central objective shall be the
establishment of a protocol and message format which may be readily
adopted by a wide variety of endpoints, minimizes client startup time
by reducing network roundtrips, and takes into consideration the
various technical challenges faced by clients in the wild, including
security, firewalls, same-origin policies and limited platform APIs.
Equally important, the working group will focus on ease of deployment,
and support for both standard and non-standard services types.  The
barriers to adoption should be made as low as possible without
compromising the security and integrity of the discovery process.

In the interest of meeting the above objectives, this working group
will develop a core message format based on JSON, and protocol based on
HTTP and REST (using [5] as the starting point).  Initially, the group
will focus on a draft defining an extensible aggregated discovery
document structure, and operations for discovery document retrieval.
The group will not necessarily define new formats and protocols, and
will consider existing technologies where possible.

Potential follow up work may include an additional draft for defining
a complimentary protocol for local area network service discovery.
This draft would define a means by which aggregated discovery
documents may be obtained by clients in a fully automated manner,
possibly based on mDNS or DHCP.  However, the group would need to
recharter in order to add such a draft to its deliverables.

Milestones:

Jun 2013 - Accept protocol and format document as Working Group item
Oct 2013 - Start Working Group Last Call on protocol and format document
Dec 2013 - Submit protocol and format document to IESG

References:

[1] RFC 2131 - DHCP
[2] RFC 6763 - DNS-SD
[3] draft-ietf-appsawg-webfinger
[4] draft-jones-simple-web-discovery
[5] draft-daboo-aggregated-service-discovery

###

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 25 Feb 2013 17:58:44 -0500

Peter, et al,

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?

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peter Saint-Andre
> Sent: Friday, February 22, 2013 1:45 PM
> To: [email-masked]
> Subject: [Aggsrv] updated charter proposal
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> The proponents have sent me an updated charter for the aggsrv initiative.
> The text can be found below, and I've also updated
> Some of these services leverage existing standards-based discovery, such
> as DNS, DHCP, or UDDI, while others may rely on some form of proprietary
> discovery.  Still others may not support any form of discovery,
> requiring the manual entry of service access information.
> be addressable through the direct use or extension of existing discovery
> protocols.  DHCP [1], for example, is widely deployed and supports
> extension for the discovery of new types of services.  Many DHCP
> extensions already exist for the discovery of such services as DNS, NTP,
> NIS, LDAP, and others.  The DHCP protocol, however, is limited by a
> dependence on local network broadcast, lack of support for structured
> data, and an extension mechanism not intended for unregistered
> customization.  This, coupled with a relative dearth of application-
> level APIs supporting DHCP service-specific extensions, makes DHCP an
> unlikely solution for the issues we face here.
> 
> However, it remains a significant limitation that the discovered data is
> global and cannot be made a function of information provided in the
> establish a solution that is broadly and uniformly usable across a wide
> array of platforms and environments.  It is an unfortunate fact that
> browser-based clients often lack the necessary APIs and trust necessary
> to make explicit DNS queries for particular types of records.
> 
> In terms of new ideas, similar discovery standardization efforts already
> under way include WebFinger [3], which is intended to address
> specific needs of service discovery use cases.  Simple Web Discovery, on
> the other hand, while expressly intended for the discovery of services,
> tends to focus specifically on service location and is not well suited
> for aggregate discovery of dissimilar service types.
> 
> Objectives:
> 
> extensible protocol supporting the discovery of multiple services with a
> single operation and with limited initial information (e.g. a well-known
> URL, or email address).  A central objective shall be the establishment
> of a protocol and message format which may be readily adopted by a wide
> variety of endpoints, minimizes client startup time by reducing network
> roundtrips, and takes into consideration the various technical
> challenges faced by clients in the wild, including security, firewalls,
> same-origin policies and limited platform APIs.
> In the interest of meeting the above objectives, this working group will
> develop a core message format based on JSON, and protocol based on HTTP
> and REST (using [5] as the starting point).  Initially, the group will
> focus on a draft defining an extensible aggregated discovery document
> structure, and operations for discovery document retrieval.
> Potential follow up work may include an additional draft for defining a
> complimentary protocol for local area network service discovery.
> This draft would define a means by which aggregated discovery documents
> may be obtained by clients in a fully automated manner, possibly based
> on mDNS or DHCP.  However, the group would need to recharter in order to
> add such a draft to its deliverables.
> 
> Milestones:
> 
> Jun 2013 - Accept protocol and format document as Working Group item Oct
> 2013 - Start Working Group Last Call on protocol and format document Dec
> 2013 - Submit protocol and format document to IESG
> 
> References:
> 
> [1] RFC 2131 - DHCP
> [2] RFC 6763 - DNS-SD
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRJ7ybAAoJEOoGpJErxa2pFMEQAJz0m+1dstov0tIwi7Qg1U7U
> mmUj5dRyNkRveyxjkEj6Ck6H396FziR023w1Qd3IpIn1WdM6Zol1CzMl59cbM8Cw
> yM33s5J2Bka4DwAfhFzXkTIG1DucwLBKjkIsiwglArqHfssEMo8vrPW3g0YZ00++
> lDVgIFJtnUfLdPq9eys1JpwH/htilXetcaglfjEFaabtCuHDCMu2PdZQ7CwhKuSP
> unnNHqELJSd1NHjZOXBuJhbq+pTJYl1MnMXbYbOHgTM96tCW9NwMA0S2R9WfZpyL
> bWwtbmsgy4vJ7Nv5BQt/BMnxei5ZsuRQAHb6G5vd9IuZVEdmgIFbRAeN4AKqasaw
> CZwLbTC387798BunfEBbPwptdilXx+lIpN+XbIRrBwt+XhEQFE1h2gVuk5woyO+Y
> 1kZlAYDVSjaIjieEabsoE/cYsvD2ItdhW7DoyarTpI/IBc9xniQHXPjrzWo4SVSb
> XFh53ouqAt3rTMLObbaTrwa2Vmg297Ksbj74Sl8kIKELsx/cfMZahn5VdLff/kAx
> ieurfO5A0VydYBWfu56xE8YBQN/Zzgljib3wIGmeHDE1cvm+BMlUkggmVVTUOR1B
> 3fIqA2mDauePvjGGXIfOAjnlAI2HYWES4Hduaddo2Gb5tADNUrdiiVxUbvZAMyod
> qmXi4JpGFcL0CLj0Ko5q
> =T6NV
> -----END PGP SIGNATURE-----
> _______________________________________________
> aggsrv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aggsrv

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 27 Feb 2013 11:10:14 -0500

Hi Paul,

--On February 25, 2013 at 5:58:44 PM -0500 "Paul E. Jones" 
<[email-masked]> 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.
>

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 27 Feb 2013 13:23:32 -0500

Cyrus,

> From: Cyrus Daboo [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2013 11:10 AM
> To: Paul E. Jones; 'Peter Saint-Andre'; [email-masked]
> Subject: Re: [Aggsrv] updated charter proposal
> 
> Hi Paul,
> 
> > definition of "rel" and "properties" values for WebFinger.  That would
> > be a good focus for the group.
> >

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

> 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.
 
> 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
> like the JRD response has to contain the "subject" member which echoes
> the resource= value. Whilst that could trivially be accomplished by, for

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

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 28 Feb 2013 11:09:48 +0200

> some JSON object that contains all of the config data.
just a question... how this related with the decision that WebFinger 
MUST run
on TLS?

cheers
/Salvatore

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 28 Feb 2013 14:48:15 +0000

>just a question... how this related with the decision that WebFinger

When used for this purpose, any protocol we pick MUST be TLS.  The whole
point of the certificate stuff in Cyrus' draft is that you can bootstrap
from the certificate that you get from the initial TLS handshake into
other protocols.

-- 
Joe Hildebrand