Re: [apps-discuss] Aggregated service discovery

Michiel de Jong <> Wed, 23 May 2012 10:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BFC421F863F for <>; Wed, 23 May 2012 03:33:35 -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 qgxs2whMM2x6 for <>; Wed, 23 May 2012 03:33:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2FE3121F8613 for <>; Wed, 23 May 2012 03:33:35 -0700 (PDT)
Received: by dacx6 with SMTP id x6so9779345dac.31 for <>; Wed, 23 May 2012 03:33:35 -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:x-gm-message-state; bh=JgMDogROquzav5WSz3ZaMKKGw8rn7NGS+mlLWezQQmY=; b=UwCFQTW/YYCjjKe/8bRDVUD6KBdtJJ15nlYg+m07RNGeOC3dB0wVLSamRRtDTS6bGL KpD5f2sEV4c/M4LGgkbAUEnsGwVMAnJXAYuwWM1HpiwOdY4Hi6FfZXsEP7Bs161ooQqW CVSEoO0FwjDufjbwnEJ4seQuhqAStiDXdbH3Ojz65vP4vPR4fPUJXQ2O+VhKlv8rkB4A 3eVtxLtz2JxHFWDpYlCjnWBReXpn17WzkzskRUF5tBF/PeIesg0ZaiT13CgYDlqbxhKG 6GXV9i7wgsElxsoChLd3DvzDmooO2meHp5Gu4TNVcNKdw7hAqBiX/4IiZoD1GcBXob7F tafA==
MIME-Version: 1.0
Received: by with SMTP id pb9mr9120260pbc.59.1337769214767; Wed, 23 May 2012 03:33:34 -0700 (PDT)
Received: by with HTTP; Wed, 23 May 2012 03:33:34 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <64C6DF43A866F40437AF4CC3@cyrus.local> <>
Date: Wed, 23 May 2012 10:33:34 +0000
Message-ID: <>
From: Michiel de Jong <>
To: Mark Nottingham <>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQkPlY5RrxNZeAUCe/Whwk2mSK/qmynFpfGKYAjYQejAAVM3H3MxLPrroIczZLg7D6FSz98F
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: Wed, 23 May 2012 10:33:35 -0000

IMO, webfinger/swd is the way to go. they are currently being merged
into one. All discovery paths should use webfinger/swd as the first
step, and then do other stuff (including requiring credentials) in
documents linked from there. There are cases where a service is
specific to a domain, but not to a user, but I think they should still
also be announced from the same first starting point (which is

how to deal with private information (meant only for the user
themselves), is not very well documented. the webfinger/swd spec
basically leaves it out of scope. Basically what you would do IMO is,
for a user "<user>@<host>", announce a first starting point at
https://<host>/.well-known/host-meta, and then use "follow your nose"
to discover everything else. That includes discovering the home-pages
of any domain-specific APIs, as well as caldav, BrowserID, OpenID,
ActivityStreams, foaf, PoCo, remoteStorage, email addresses, avatars,
and everything else. The first starting point should be available
without credentials, publicly, and with CORS headers on there. Then as
you follow the links to all these services, you will find barriers
where maybe a bearer token or a client-side certificate or something
else is needed to retrieve the next bit of information.

But the first starting point should always be public, on
/.well-known/host-meta and with CORS headers on there. Even if it's
just to say "nothing to see here unless you can give me credentials of
type X" (IMO, OAuth end-point discovery can itself serve here as a
syntax for expressing that, although i think announcing
credentials-requirements is still a relatively under-explored part of
discovery best practices).