Re: Client as Server: auth use case

On 27/01/21 3:20 am, Henry Story 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.
> 


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

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

Received on Wednesday, 27 January 2021 04:38:37 UTC