Re: Request for advice

Paul Millar <> Thu, 18 February 2016 17:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E18B21B3140 for <>; Thu, 18 Feb 2016 09:20:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.006, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3CRZU6qt5d9r for <>; Thu, 18 Feb 2016 09:20:09 -0800 (PST)
Received: from ( [IPv6:2001:638:700:1038::1:9c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3292D1B3149 for <>; Thu, 18 Feb 2016 09:20:09 -0800 (PST)
X-Clacks-Overhead: GNU Terry Pratchett
Received: from ( []) by (DESY-O-3) with ESMTP id B54E6280372 for <>; Thu, 18 Feb 2016 18:20:06 +0100 (CET)
Received: from ( []) by (DESY_MAP_3) with ESMTP id A814D46EC for <>; Thu, 18 Feb 2016 18:20:06 +0100 (MET)
Received: from ( by (Clearswift SMTPRS 5.5.0) with ESMTP id <>; Thu, 18 Feb 2016 18:20:06 +0100
Received: from [] ( []) by (DESY-INTRA-1) with ESMTP id 311953E901; Thu, 18 Feb 2016 18:20:06 +0100 (MET)
Subject: Re: Request for advice
To: Mark Nottingham <>
References: <> <>
From: Paul Millar <>
Message-ID: <>
Date: Thu, 18 Feb 2016 18:20:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Well-Known URI review list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Feb 2016 17:20:11 -0000

Hi Mark,

On 11/02/16 01:33, Mark Nottingham wrote:
>> Would both approach be acceptable, or should we focus on option b.
>> ?
> (b) gives people who deploy more flexibility, in that they can direct
> clients to a different server, etc. This is especially helpful when
> you're expecting a POST, because if you want to redirect them,
> they'll have to retransmit the request body (unless both sides
> support expect/continue, which has proven problematic over the
> years).
> It's true that this way requires an extra request, but the response
> can be cached.

Thanks for the comments.  We're currently focusing on option b (adding a 
discovery/configuration endpoint)

> One question -- are you using a .well-known to enable someone to find
> out something about the host, or is it just a convenience?
> I.e., is it acceptable for your service to take a full URL as an
> input instead of a hostname?

I suppose a full URL could be provided, but the idea is to decouple this 
service from those using it.

I'm not sure if this is off-topic for this list, but perhaps this is 
clearer if I explain more about the purpose.

The goal is to define an end-point to allow clients to request a 
particular kind of bearer token call macaroons, which have some 
advantages over regular bearer tokens.

The current idea is that any service that accepts these bearer tokens 
will provide an endpoint at /.well-known/macaroon-configuration 
(deliberately a similar name to OpenID-Connect) where clients can issue 
a GET request and the response is a JSON object containing information. 
  One piece of information in that JSON object is the location of the 
macaroon minting endpoint.

As you say, this provides the flexibility to have multiple front-end 
machines redirect to a common minting endpoint on some other machine.

While it would be possible to extend existing protocols to allow clients 
to discover the macaroon minted endpoint in a protocol-specific fashion, 
using a /.well-known entry would decouple the macaroon discovery from 
protocol, which could bring benefits in terms of code reuse.