Re: Client as Server: auth use case

[Cory Benfield <[e-mail]>]

This is an idea that comes up a lot. In fact, it has come up so much
that I wrote a draft that would attempt to encode this idea in HTTP/2
back in 2015. https://tools.ietf.org/html/draft-benfield-http2-p2p-02

The issue I bumped into then is the same one that faces you now.
Specifying this behaviour is not terribly hard: demonstrating that
it's sufficiently useful to implement is. It is likely to be
substantially more useful to attempt to actually deploy such an
extension in a controlled environment and demonstrate its utility in
that space, then return with a specification.

Cory

On Tue, 26 Jan 2021 at 14:23, Henry Story <[e-mail]> wrote:
>
> Hi,
>
>    I was wondering if the newer versions of HTTP (perhaps Quic)
> can allow the server to make a request back to the client as
> an HTTP request. This could be useful for exchanging keys or
> certificates in a RESTful way.
>
> As an example take the "Signing HTTP Messages” spec, which has a
> keyId field. The value placed there could be a full URL (did, https, …)
> pointing to a key on the web, or it could be a key stored on
> the client with a relative URL path. This would allow the server
> for that connection make a simple HTTP GET request on that
> relative URL to the client.  (These relative urls function here
> as indexicals as ”you” and ”I” in a conversation between two
> people).
>
> Going further the client might want to add a ”Credential: …” header
> with as value a URL. This could be a full URL pointing to a credential
> on the Web, or perhaps a relative URL to be resolved by the server
> by asking the client.
>
> The value is that in both cases if the server has cached the key
> or credential it would not need to be fetch it again. Another one
> is that key material and credentials would not need to be fetched
> on the web - reducing dependency on other services, requiring credentials
> to be published, …
>
> One would need to make a distinction between relative URLs
> to be resolved on $you the server or $me the client.
>
> There may be many other use cases for allowing the server
> to make requests to the client on the same connection.
>
> Thanks in advance,
>
>
> [1] https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-01
>
> Henry Story
>
> https://co-operating.systems
> WhatsApp, Signal, Tel: [phone]‬
> Twitter: @bblfish
>