Subject: Client as Server: auth use case

From: Henry Story <[email-masked]>
Date: Tue, 26 Jan 2021 15:20:26 +0100

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: +33 6 38 32 69 84‬
Twitter: @bblfish

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 27 Jan 2021 17:35:02 +1300

> certificates in a RESTful way.

There is no way for the server to know which clients will sometime in 
*future* connect to it.

When the server does receive a request from some client the message 
which goes to the client requesting credentials is called a response. 
The REST'ful way is pretty much exactly how HTTP auth works today.

> as indexicals as ”you” and ”I” in a conversation between two

Or, the client could deliver the required key in its initial request.

Or, the server could deliver a 401/407 response to the client to inform 
it that future requests with credentials will receive the data. Along 
with any details the client needs to identify which credentials are needed.

AYJ

---

From: Cory Benfield <[email-masked]>
Date: Wed, 27 Jan 2021 10:04:13 +0000

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