Re: [apps-discuss] Aggregated service discovery

Michiel de Jong <michiel@unhosted.org> Tue, 29 May 2012 12:23 UTC

Return-Path: <michiel@unhosted.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3C221F87D5 for <apps-discuss@ietfa.amsl.com>; Tue, 29 May 2012 05:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua3+IfPMXFvg for <apps-discuss@ietfa.amsl.com>; Tue, 29 May 2012 05:23:00 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2151621F8754 for <apps-discuss@ietf.org>; Tue, 29 May 2012 05:23:00 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so5788132pbc.31 for <apps-discuss@ietf.org>; Tue, 29 May 2012 05:23:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=8hqtii8U4FH5zw1iPFqJSYJIPsX1pgRa7NZpFAGJDA0=; b=HdTBvFTcwpzx2pJa30Im6HfpKDyUl6AEZMes23bWgzu/iouToxOpVW5sYa3gmbvCrB ykaJY9qLIQfmMG06S/Uw/LUfQ6lxd8wMb3CF3YUAh5L8j1BCj5B86HobXheDFuAuFJdt 2Pwwy2Xag3P9+nZ8ATnjrP9NxXNOSPcGcEWANdEjoOeL5T+KbHVu6SyKEhL+N8wnnzKa it8t60mXMb1JqyZAXbcLu4mCUpOyBMdOwu7wU+IENSD3C5ouW3Y9GVrFU+K6di+1UG4r Ph3kan7ZheyelLa3jxnrSYnbtEc2WSiXJdlKqjciEbiFuGzFdjkd9SIF1TzX6MLo4mjP BFAw==
MIME-Version: 1.0
Received: by 10.68.219.162 with SMTP id pp2mr37494621pbc.85.1338294179780; Tue, 29 May 2012 05:22:59 -0700 (PDT)
Received: by 10.68.57.102 with HTTP; Tue, 29 May 2012 05:22:59 -0700 (PDT)
X-Originating-IP: [188.205.40.198]
In-Reply-To: <1338090233.6923.328.camel@dave.home.mcmillan.net.nz>
References: <64C6DF43A866F40437AF4CC3@cyrus.local> <22873D37-8462-48AE-ABA0-49445776E4CC@mnot.net> <FF3DD3C9968F397579BC846A@cyrus.local> <92CD7BC1-4A4C-49BD-8F4B-4A04BC63620F@mnot.net> <1337835271.6923.275.camel@dave.home.mcmillan.net.nz> <CA+aD3u0AJ0B4j8YrF4-M7+FmoAJnFzWvYJJ-F8vV87Z3=Y67rQ@mail.gmail.com> <4FBF3F93.2010302@tana.it> <1338090233.6923.328.camel@dave.home.mcmillan.net.nz>
Date: Tue, 29 May 2012 14:22:59 +0200
Message-ID: <CA+aD3u0CexzTFg1r47ZZ45tt5t2Qbs6PO-1uKNRoPdNtH4YN+w@mail.gmail.com>
From: Michiel de Jong <michiel@unhosted.org>
To: andrew@morphoss.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkSya/gtXtT4o+LONRfYRJAXaIFb+IPRsxf+LLLgjFp4I4UTQs1BMa+wWLlBUoKLqQVN6KF
Cc: apps-discuss@ietf.org, Alessandro Vesely <vesely@tana.it>
Subject: Re: [apps-discuss] Aggregated service discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2012 12:23:01 -0000

in the remoteStorage spec we are using webfinger to discover a
personal data service. relying on network topology for security is not
an option here, and nor are SRV records, because we want to be able to
link any unhosted html5 app to any remoteStorage server. This is still
very much a draft, and we're still changing the link format around,
but our current proposal is this:

http://www.w3.org/community/unhosted/wiki/Pds

Basically, our example (publicly) announces the following service
attributes for a Read-Write Web (rww) server over public
webfinger+CORS:

- service base address
- service API version
- auth method
- auth end-point

I would love to get feedback on they way we're doing that discovery
there, and if anybody knows a more standard way to achieve the same
thing.


Cheers!
Michiel.

On Sun, May 27, 2012 at 5:43 AM, Andrew McMillan <andrew@morphoss.com> wrote:
> On Fri, 2012-05-25 at 10:15 +0200, Alessandro Vesely wrote:
>> On Thu 24/May/2012 16:30:03 +0200 Michiel de Jong wrote:
>>
>> > but the main objection people would have to doing this is i think
>> > privacy/security. you don't want to announce the exact details of all
>> > your services publically, because:
>> > 1) it makes it easier for an attacker to know where to attack your systems
>> > 2) it may reveal non-public information about your users unnecessarily.
>>
>> Requiring authentication in order to discover the services would seem
>> to be a relevant functional difference w.r.t. SRV records.  I, for
>> one, don't use SRV records because of those two reasons.
>
> I can definitely understand that reasoning, and it's a good point in
> favour of a more securable alternative.  You could also make the
> relevant SRV records available only on your private networks, but then
> that can result in a complex and fragile DNS setup.
>
>
>> Of course, directing all mass, blind dictionary attacks toward a
>> single entry point will call from some savvy implementation advice.
>> For example, centralized discovery could count failed attempts and
>> block a user when that number becomes comparable to her password's
>> entropy.  She won't be able to install new client devices for a while,
>> but that is much less disruptive than blocking IMAP access.
>
> I can see plenty of value in an administrator putting the discovery
> point inside a corporate (or ISP) firewall in order to reduce the value
> to automated external attackers.  Or having alternative representations
> of the discovery with only limited visible services for external
> visitors.  Analogously, a manual system of providing these configuration
> parameters could well place them inside a firewall on internal
> documentation.
>
> I would like to see a scheme which had significant utility with only a
> single static document providing the information.  More advanced
> implementations may well produce that document dynamically, but these
> parameters are not expected to be very changeable values in most
> installations.
>
> Regards,
>                                        Andrew.
> --
> ------------------------------------------------------------------------
> andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
>        Open Source: the difference between trust and antitrust
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>