Subject: Request for advice

From: Paul Millar <[email-masked]>
Date: Wed, 10 Feb 2016 13:14:44 +0100

Hi,

I am working within a small team devising a new HTTP-based protocol.  We 
hope to use a /.well-known URI and register this protocol with IANA.

The protocol involves the client issuing a POST request to the server 
and receiving some information back; i.e., this is not a lookup (GET or 
HEAD) request.

As I see it, there are two options:

a.	client issues POST requests directly to a well-known
	endpoint; e.g., /.well-known/<foo>

b.	client issues GET request to /.well-known/<foo-discovery>
	endpoint.  The response describes the location of <foo>.
	The client makes POST request to that URI.

Option a. has some advantages in terms of latency and reduced 
complexity; however, it seems from RFC 5785 that the latter option is 
more in line with the intended use of /.well-known.  Option b. is also 
the approach taken by most other registrants (e.g., OpenID-Configuration)

Would both approach be acceptable, or should we focus on option b. ?

Cheers,

Paul.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Feb 2016 11:33:21 +1100

Hi Paul,

> On 10 Feb 2016, at 11:14 pm, Paul Millar <[email-masked]> wrote:
> 
> Hi,
> 
> I am working within a small team devising a new HTTP-based protocol.  We hope to use a /.well-known URI and register this protocol with IANA.
> 
> The protocol involves the client issuing a POST request to the server and receiving some information back; i.e., this is not a lookup (GET or HEAD) request.
> 
> Option a. has some advantages in terms of latency and reduced complexity; however, it seems from RFC 5785 that the latter option is more in line with the intended use of /.well-known.  Option b. is also the approach taken by most other registrants (e.g., OpenID-Configuration)
> 

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

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? 

Cheers,

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

---

From: Paul Millar <[email-masked]>
Date: Thu, 18 Feb 2016 18:20:06 +0100

Hi Mark,

On 11/02/16 01:33, Mark Nottingham wrote:
> (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).
>

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

Cheers,

Paul.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 19 Feb 2016 12:20:53 +1100

Hi Paul,

> On 19 Feb 2016, at 4:20 AM, Paul Millar <[email-masked]> wrote:

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

---

From: Christopher Gutteridge <[email-masked]>
Date: Fri, 19 Feb 2016 08:58:41 +0000

It could be used to discover other protocols by indirection. Either the 
way we're doing it, by returning a data document containing more 
information, or if its' a single URI, an HTTP redirect.

Mark, is their any precedent for that. eg. you could have
http://example.com/.well-known/webmaster redirect to 
mailto:[email-masked]

Just an idea...

On 19/02/2016 01:20, Mark Nottingham wrote:
> _______________________________________________
> wellknown-uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wellknown-uri-review

-- 
Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg

University of Southampton Open Data Service: http://data.southampton.ac.uk/
You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/