Re: Request for advice

[Paul Millar <[e-mail]>]

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.

Cheers,

Paul.