Re: Request for advice

Mark Nottingham <mnot@mnot.net> Fri, 19 February 2016 01:21 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: wellknown-uri-review@ietfa.amsl.com
Delivered-To: wellknown-uri-review@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44011A86EE for <wellknown-uri-review@ietfa.amsl.com>; Thu, 18 Feb 2016 17:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trxd7adQwWB8 for <wellknown-uri-review@ietfa.amsl.com>; Thu, 18 Feb 2016 17:20:58 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC101A6FC9 for <wellknown-uri-review@ietf.org>; Thu, 18 Feb 2016 17:20:58 -0800 (PST)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BFD8422E261; Thu, 18 Feb 2016 20:20:56 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: Request for advice
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <56C5FD46.9040305@desy.de>
Date: Fri, 19 Feb 2016 12:20:53 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E7C2172-AE73-4B58-B38E-1904FE27996F@mnot.net>
References: <56BB29B4.8090106@desy.de> <8D9CE563-5FF8-4C6A-BF54-C928CCCC60E2@mnot.net> <56C5FD46.9040305@desy.de>
To: Paul Millar <paul.millar@desy.de>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/wellknown-uri-review/RC9Zc3cGzBI4PPCmHcFS44SUGCM>
Cc: wellknown-uri-review@ietf.org
X-BeenThere: wellknown-uri-review@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Well-Known URI review list <wellknown-uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wellknown-uri-review>, <mailto:wellknown-uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wellknown-uri-review/>
List-Post: <mailto:wellknown-uri-review@ietf.org>
List-Help: <mailto:wellknown-uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wellknown-uri-review>, <mailto:wellknown-uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2016 01:21:01 -0000

Hi Paul,

> On 19 Feb 2016, at 4:20 AM, Paul Millar <paul.millar@desy.de> wrote:

>> 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.

Hmm. .well-known is specifically limited to HTTP and HTTPS - what other protocols did you want to use?


--
Mark Nottingham   https://www.mnot.net/