From stpeter@stpeter.im Wed Feb 20 12:01:11 2013 Return-Path: X-Original-To: aggsrv@ietfa.amsl.com Delivered-To: aggsrv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C235821F8798 for ; Wed, 20 Feb 2013 12:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liCahapHCpBZ for ; Wed, 20 Feb 2013 12:01:10 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7D121F86D6 for ; Wed, 20 Feb 2013 12:01:04 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3CBB84067B for ; Wed, 20 Feb 2013 13:08:32 -0700 (MST) Message-ID: <51252B7E.1010108@stpeter.im> Date: Wed, 20 Feb 2013 13:01:02 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: aggsrv@ietf.org X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Aggsrv] Aggregated Service Discovery BoF X-BeenThere: aggsrv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Aggregated Service Discovery \(aggsrv\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:01:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, There will be a BoF in Orlando on the topic of aggregated service discovery, focusing on the problem of how clients can discover both application servers and configuration information for multiple protocols at once. The intent is to form a relatively short-lived, single-purpose working group. You can read more here: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/AggSrv https://datatracker.ietf.org/doc/draft-daboo-aggregated-service-discovery/ A dedicated email list has been established: https://www.ietf.org/mailman/listinfo/aggsrv Your feedback is welcome! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJSt+AAoJEOoGpJErxa2pqL8P+wX59nosjFM87DDLH9IF4XhI MEkz5G6pOXJikamokCGc34zdvW0tdAHBfL6OjjC0yHEwENwXMhHUfwTxAJQDDUvq VJzdR8FfUOHjBMrWif2sXWnEWbBtAZU24BL2W0NLxFVA8+s8JEdbUX6QjrcPD7I7 E4vbovjNe8FBQYZbp0I68iz4zeXc0jGGPghBDXC5NbuT+WJm2vUFf/9UaEpY3LS+ SaOtBcZouK45jPZ/xLvzlP3zFeTb/SdBLVYk5iYc0O2A/eV1K9oL+ie8bki9QQZ9 JNVRTXdtVTbtTv1l1Lxm+vimXS6Q2PZGxRnUwdd/jyeiop3vLR8TG3HF1weGtLSb U379+BdimP7lYpf889kOjj0lsmLk3aM8refTeJm55g5CNqTJQGiadjUtg1PxifAt z7Xn4TndJRNbs1mu02OjRmyvA/+/oYwEuAf04fE3IbF+bNTg3yJzpZGly9/ZUZhI JiY+SwQN+MelW26qJftSi8xqgsf3b6s+3aGGBTrhXbGkbvoEq7Zwd5MNTrgGqovc I2cHrJj3YRonG3L5/DgW5UBn+DOvJYc7N1vnMYa2c7OnHRluv6VAWvJEiB6bckXh Oz+WOZoZppa/eUYgu5cStzOp6rsSg+IjpFSy5oGvUWP1S5vZGYjtaHWWq6Cuc6aR Gc7vndykPt16fPW2YWmS =bHq6 -----END PGP SIGNATURE----- From laurentwalter.goix@telecomitalia.it Wed Feb 20 14:25:28 2013 Return-Path: X-Original-To: aggsrv@ietfa.amsl.com Delivered-To: aggsrv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B772221F86E7 for ; Wed, 20 Feb 2013 14:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhnQEk5tvDvv for ; Wed, 20 Feb 2013 14:25:27 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3E121E803A for ; Wed, 20 Feb 2013 14:25:26 -0800 (PST) Content-Type: multipart/mixed; boundary="_00e088e1-0fd5-4edc-bb6b-a27d2d5d041a_" Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 20 Feb 2013 23:25:25 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Wed, 20 Feb 2013 23:25:25 +0100 From: Goix Laurent Walter To: "aggsrv@ietf.org" Date: Wed, 20 Feb 2013 23:25:24 +0100 Thread-Topic: ASD vs WebFinger Thread-Index: Ac4PuS2SWJQapjWAR4qwWHOCCck3aQ== Message-ID: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Subject: [Aggsrv] ASD vs WebFinger X-BeenThere: aggsrv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Aggregated Service Discovery \(aggsrv\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:25:28 -0000 --_00e088e1-0fd5-4edc-bb6b-a27d2d5d041a_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A7694CBBGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A7694CBBGRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I'm quite new to the ASD draft and would be interested in better understand= ing the difference wrt Webfinger draft. At a first glance in fact many conc= epts seem similar (well-known endpoint, minimum user/resource identifier as= query parameter, json response). The use case of autoconfiguration is also achievable with webfinger so what= is the exact value of this draft that cannot be addressed with the other? = This may worth to be mentioned in the draft itself as a differentiation Thank you walter ------------------------------------------------------------------ Telecom Italia Laurent-Walter Goix Innovation & Industry Relations, Research & Prototyping, Future Internet Piazza Einaudi 8 - 20124 Milano (Italy) Tel. +39 026213445 Mob. +39 3356114196 Fax +39 0641869055 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A7694CBBGRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I’m quite new to the ASD = draft and would be interested in better understanding the difference wrt We= bfinger draft. At a first glance in fact many concepts seem similar (well-k= nown endpoint, minimum user/resource identifier as  query parameter, json response).

The use case of autoconfigurati= on is also achievable with webfinger so what is the exact value of this dra= ft that cannot be addressed with the other? This may worth to be mentioned = in the draft itself as a differentiation

 

Thank you

walter

 

----------------------------------------------------------------= --
Telecom Italia
Laurent-Walter Goix=

Innovation & Industry= Relations, Research & Prototyping, Future Internet 

Piazza Einaudi 8 - 2012= 4 Milano (Italy)
Tel. +39 026213445

Mob. +39 3356114196

Fax +39 0641869055

 =

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A7694CBBGRFMBX704BA02_-- --_00e088e1-0fd5-4edc-bb6b-a27d2d5d041a_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_00e088e1-0fd5-4edc-bb6b-a27d2d5d041a_-- From stpeter@stpeter.im Fri Feb 22 10:44:51 2013 Return-Path: X-Original-To: aggsrv@ietfa.amsl.com Delivered-To: aggsrv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63E721F8A90 for ; Fri, 22 Feb 2013 10:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaC4ekKnruwC for ; Fri, 22 Feb 2013 10:44:50 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9B81B21F89A3 for ; Fri, 22 Feb 2013 10:44:50 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 86710403CD for ; Fri, 22 Feb 2013 11:52:24 -0700 (MST) Message-ID: <5127BC9B.8000203@stpeter.im> Date: Fri, 22 Feb 2013 11:44:43 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: aggsrv@ietf.org X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Aggsrv] updated charter proposal X-BeenThere: aggsrv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Aggregated Service Discovery \(aggsrv\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 18:44:51 -0000 -----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 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/ -----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----- From paulej@packetizer.com Mon Feb 25 14:58:48 2013 Return-Path: X-Original-To: aggsrv@ietfa.amsl.com Delivered-To: aggsrv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C14221E80FE for ; Mon, 25 Feb 2013 14:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1oUtZ5qBhal for ; Mon, 25 Feb 2013 14:58:47 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 170D621E8134 for ; Mon, 25 Feb 2013 14:58:44 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1PMwe3o011696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Feb 2013 17:58:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361833121; bh=F8a5a9ZYxU8t1UFiH0ViauTKAd3Lna+GN9KYOMaV5FE=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=I2WVTmRiZyl/0ptmvova5pFq/h/0UZbNgG/f/fRk/+Aav0SnNW0NbiJyFwoiVgnAV kGL/L2ZwrqP1/RcpmMSt36eGoyS1lp4sxDae4q1bNSbAOTVJVY7CLW8+jwE5Z0NAxa 4ChXVPweVi+6xO1UVxirYQ4hFtEbJWqWjRYBzkA0= From: "Paul E. Jones" To: "'Peter Saint-Andre'" , References: <5127BC9B.8000203@stpeter.im> In-Reply-To: <5127BC9B.8000203@stpeter.im> Date: Mon, 25 Feb 2013 17:58:44 -0500 Message-ID: <01f701ce13ab$a9def660$fd9ce320$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDwSaYLA9DbEJOVMCQUxjyWUnEXJppGwRsA Content-Language: en-us Subject: Re: [Aggsrv] updated charter proposal X-BeenThere: aggsrv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Aggregated Service Discovery \(aggsrv\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:58:48 -0000 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: aggsrv-bounces@ietf.org [mailto:aggsrv-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Friday, February 22, 2013 1:45 PM > To: aggsrv@ietf.org > 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 > 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/ > > -----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 > aggsrv@ietf.org > https://www.ietf.org/mailman/listinfo/aggsrv From cyrus@daboo.name Wed Feb 27 08:10:20 2013 Return-Path: X-Original-To: aggsrv@ietfa.amsl.com Delivered-To: aggsrv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20D321F8611 for ; Wed, 27 Feb 2013 08:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNpCbh2dvanp for ; Wed, 27 Feb 2013 08:10:20 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id DBF6F21F8545 for ; Wed, 27 Feb 2013 08:10:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 764963E2A5E3; Wed, 27 Feb 2013 11:10:19 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMJaexLKSoHM; Wed, 27 Feb 2013 11:10:18 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id CBC373E2A5D0; Wed, 27 Feb 2013 11:10:17 -0500 (EST) Date: Wed, 27 Feb 2013 11:10:14 -0500 From: Cyrus Daboo To: "Paul E. Jones" , 'Peter Saint-Andre' , aggsrv@ietf.org Message-ID: In-Reply-To: <01f701ce13ab$a9def660$fd9ce320$@packetizer.com> References: <5127BC9B.8000203@stpeter.im> <01f701ce13ab$a9def660$fd9ce320$@packetizer.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2681 Subject: Re: [Aggsrv] updated charter proposal X-BeenThere: aggsrv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Aggregated Service Discovery \(aggsrv\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:10:20 -0000 Hi Paul, --On February 25, 2013 at 5:58:44 PM -0500 "Paul E. Jones" 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 From paulej@packetizer.com Wed Feb 27 10:23:35 2013 Return-Path: X-Original-To: aggsrv@ietfa.amsl.com Delivered-To: aggsrv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4604021F84BE for ; Wed, 27 Feb 2013 10:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v++MLf4gxY6x for ; Wed, 27 Feb 2013 10:23:34 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3A321F84A6 for ; Wed, 27 Feb 2013 10:23:33 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1RINPfq015471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 13:23:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361989407; bh=BBhEQr4oTnXH25aPsUn/4/DNCC6JxaXtuHDliPkoPgs=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=XCHu35TdsIdHwR5Rqa/UINchyfSvl/yJ7dvXWRLV3mH/KpYCJSEVt6XjPAIFJZXJq sWsGEiKtB68zlUAZZLcK2DxmvVlaeYsLCQKWN4NKoKatL/TLFVYBZKGyBNVXEhT4Ls YwZqaXKX4IDYbtclEPIq7AwLVRpsn2+AfC2Lq38Y= From: "Paul E. Jones" To: "'Cyrus Daboo'" , "'Peter Saint-Andre'" , References: <5127BC9B.8000203@stpeter.im> <01f701ce13ab$a9def660$fd9ce320$@packetizer.com> In-Reply-To: Date: Wed, 27 Feb 2013 13:23:32 -0500 Message-ID: <011601ce1517$8df64080$a9e2c180$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDwSaYLA9DbEJOVMCQUxjyWUnEXJgLO0C3RAsg+hhSaHMuLAA== Content-Language: en-us Subject: Re: [Aggsrv] updated charter proposal X-BeenThere: aggsrv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Aggregated Service Discovery \(aggsrv\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:23:35 -0000 Cyrus, > -----Original Message----- > From: Cyrus Daboo [mailto:cyrus@daboo.name] > Sent: Wednesday, February 27, 2013 11:10 AM > To: Paul E. Jones; 'Peter Saint-Andre'; aggsrv@ietf.org > Subject: Re: [Aggsrv] updated charter proposal > > Hi Paul, > > --On February 25, 2013 at 5:58:44 PM -0500 "Paul E. Jones" > 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 From salvatore.loreto@ericsson.com Thu Feb 28 01:09:56 2013 Return-Path: X-Original-To: aggsrv@ietfa.amsl.com Delivered-To: aggsrv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F368F21F84B1 for ; Thu, 28 Feb 2013 01:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.172 X-Spam-Level: X-Spam-Status: No, score=-106.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hPhYqa1Q8o9 for ; Thu, 28 Feb 2013 01:09:54 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2AD21F84AF for ; Thu, 28 Feb 2013 01:09:50 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-64-512f1edd7fd9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 77.78.19728.DDE1F215; Thu, 28 Feb 2013 10:09:50 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 28 Feb 2013 10:09:50 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7E46C2B36 for ; Thu, 28 Feb 2013 11:09:49 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 37A3A54591 for ; Thu, 28 Feb 2013 11:09:47 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 82A77544EC for ; Thu, 28 Feb 2013 11:09:46 +0200 (EET) Message-ID: <512F1EDC.6000008@ericsson.com> Date: Thu, 28 Feb 2013 11:09:48 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: aggsrv@ietf.org References: <5127BC9B.8000203@stpeter.im> <01f701ce13ab$a9def660$fd9ce320$@packetizer.com> <011601ce1517$8df64080$a9e2c180$@packetizer.com> In-Reply-To: <011601ce1517$8df64080$a9e2c180$@packetizer.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvje49Of1Ag2m72S1WzW5hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtUHS1kKXnJUtBx9x9rA2MvexcjJISFgInH+/EVWCFtM4sK9 9WxdjFwcQgInGSV2PtvFCuFsYJT4f6wbyrnAKPFyz0UWCOcwo0R302tmCOcMo8SLyadYQIbx CmhLnNlwjBHEZhFQlVi+5R7YEjYBM4nnD7cwg9iiAskS/x4dYYSoF5Q4OfMJWK+IgLDEiv+T gGo4OIQF9CTaHgVDzN/DKPGw9RobSA2ngK3Eh3l7wGYyA9kX5lxngbDlJba/ncMM8ZCaxNVz m8BsIQEtid6znUwTGEVmIVk3C0n7LCTtCxiZVzGy5yZm5qSXG21iBIbzwS2/VXcw3jkncohR moNFSZw33PVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGrqBT9gES0n0stziFWddnhnUL XJczr8vZK/24Q2vVt8NXTVK6+R21nD7VTt5qubanwL3uUyF7ZecKxkylQ1dU5k7hmvxej42h u8nv7PSU7FV7r15e2+YoNkPIs2nTt7JjF2tbqla/2lTx/GLB6UWCUoc4EpRdyx5lbVstLK/n t2b+wbJk68tKLMUZiYZazEXFiQCS6kvZNQIAAA== Subject: Re: [Aggsrv] updated charter proposal X-BeenThere: aggsrv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Aggregated Service Discovery \(aggsrv\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 09:09:56 -0000 On 2/27/13 8:23 PM, Paul E. Jones wrote: >> >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. > just a question... how this related with the decision that WebFinger MUST run on TLS? cheers /Salvatore From jhildebr@cisco.com Thu Feb 28 06:48:25 2013 Return-Path: X-Original-To: aggsrv@ietfa.amsl.com Delivered-To: aggsrv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A90F21F8A5F for ; Thu, 28 Feb 2013 06:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfCrHxPzh82K for ; Thu, 28 Feb 2013 06:48:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C884521F8991 for ; Thu, 28 Feb 2013 06:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=438; q=dns/txt; s=iport; t=1362062896; x=1363272496; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=RfJ6vJXfSj/MH4BwqjYC3kSkKa1FF8VFW7rQiwFWBnU=; b=CY6R42Oe6NPqxhovxaIths/FqOQgg1FmWjMluR0x+wZfdgD3h1iLlpNd unM5cDEXl3fH0U83/oou/nGRmQiJ3HOEna9WbrIaNJ0++mzBXcSaFee5l sGez05gE+mmhyknmZ5gZ7/ZjVOnshuUyYTfkx/m5TQQIN4CDz4JIIl6oG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAOtsL1GtJV2b/2dsb2JhbABFhgi8JHoWc4IhAQQ6UQEIIhRCJQIEARIIiAvBeY5jOIJfYQOnK4MIgic X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="182229811" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 28 Feb 2013 14:48:15 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1SEmFDn018300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Feb 2013 14:48:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 08:48:15 -0600 From: "Joe Hildebrand (jhildebr)" To: Salvatore Loreto , "aggsrv@ietf.org" Thread-Topic: [Aggsrv] updated charter proposal Thread-Index: AQHOFZNhWQXRA7Fb4Uid0cMJ4PQTJpiPSVqA Date: Thu, 28 Feb 2013 14:48:15 +0000 Message-ID: In-Reply-To: <512F1EDC.6000008@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.21.92.93] Content-Type: text/plain; charset="us-ascii" Content-ID: <783B054F1A24CF47BD7473AC6486222D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Aggsrv] updated charter proposal X-BeenThere: aggsrv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Aggregated Service Discovery \(aggsrv\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:48:25 -0000 On 2/28/13 2:09 AM, "Salvatore Loreto" wrote: >just a question... how this related with the decision that WebFinger >MUST run >on TLS? 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. --=20 Joe Hildebrand