Re: [apps-discuss] Aggregated service discovery

Michiel de Jong <> Thu, 24 May 2012 14:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9025521F8534 for <>; Thu, 24 May 2012 07:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JNT7i5MdPyOM for <>; Thu, 24 May 2012 07:30:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0974121F851B for <>; Thu, 24 May 2012 07:30:04 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so335818pbc.31 for <>; Thu, 24 May 2012 07:30:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=qu+8SEHjtmE2X2fiSJzOONBshT++WR+ToIKX/rpAVkU=; b=iU0vgB764hNAzIRzQ2mb14ibJUs01XRrqcFJK8yjUo9KOnzur5CoQAhJdxuUlCsLla MXPUyW6MQpCUA9dxAkehwnEkPj3oXJfCitZUWhqbk+yJufAbU3fQIw+BJSQzlf/4t/2+ Llj1y9PhC3WoWPHfGuS07F1ZiP41ChIPQrLxsm8N9pPsvKA3xILhFQca35wg+rbfDioC xvlL36NVsx86hrKxGo6fXKd3VBhT431/M3V8kp0ylXiR70DzP9puu0VcH46M6Zfgf+lK V3MMuvEMMoNT0AHTrK+XWbVMhgpRN1/4ERybCkzmCzAAwWRBHU4CA6JIWBEjC8acrw/0 ATQg==
MIME-Version: 1.0
Received: by with SMTP id nd10mr22167099pbc.68.1337869803798; Thu, 24 May 2012 07:30:03 -0700 (PDT)
Received: by with HTTP; Thu, 24 May 2012 07:30:03 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <64C6DF43A866F40437AF4CC3@cyrus.local> <> <FF3DD3C9968F397579BC846A@cyrus.local> <> <>
Date: Thu, 24 May 2012 14:30:03 +0000
Message-ID: <>
From: Michiel de Jong <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlVSJ+/PpO/G/EQUO5rGPxum1BT2DFh/x4lRoOejGeXdl4iRutejXYTvD9CAkldwnOah7SC
Subject: Re: [apps-discuss] Aggregated service discovery
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 May 2012 14:30:04 -0000

On Thu, May 24, 2012 at 4:54 AM, Andrew McMillan <> wrote:
> The UI would be that I have three 'facts' and I would like to use these
> to configure my $SERVICE.  I'd like to be able to supply the same three
> facts for any service and hope that my software was able to hide further
> complexity from me, ideally supplying them only once, and authorizing
> each client on first use.
> I believe those facts should be:
> * A domain name
> * A username
> * Some authentication token(s)
> Of course the domain name could be a URL, but in providing a standard
> simplification a domain name offers the advantage that it is shorter
> than a URL, and if we then define a set of standard transformations to
> that domain name (such as an SRV lookup to discover protocols, hosts and
> ports, and appending some standard path) we can save my mother a lot of
> laborious and error-prone data entry on her smartphone.
> Regards,
>                                        Andrew McMillan.

i find this a super interesting question. i have been thinking about
this as well, and i think we don't have a good solution for this right
now, so it would be cool to change that. aspects i see:

1: Existence - listing which services even exist
2: Version - which version of the spec the instance claims to be compliant with
3: End-points - this is service-specific
4: Options - which types of encryption, signature, encodings, etc. are supported

i think these 4 types of discoverable information make sense for most
services. And i think if we combine webfinger/swd with json-home, then
we probably have enough expressive power to announce these 4 types of
information in a sensible way.

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.

Given that the user story Andrew describes (and i think this is the
correct thing to be looking at), starts out with a domain identifier,
a user identifier within that domain, and some authentication
token(s). If we have a trusted client then we can already use those
tokens during the discovery. In other cases we would have to use maybe
OAuth or similar to get derived tokens for doing the actual discovery.
If we do that, then we need to announce that that is the case. In the
case where you use resource owner password credentials, then i can see
how you could discover everything you want in 1 round trip. if you use
derived credentials (e.g. implicit grant), then i think 3 round-trips
are unavoidable: one to discover the discovery and OAuth end-points,
one to obtain the derived token, and one to do the actual lookup with

My 2ct,