Client as Server: auth use case

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