HTTP-Sig was: Client as Server: auth use case

Hi,

  I wrote up how Signing-HTTP messages can work with our Solid use case
and referred to Cory Benfield's Spec as a very elegant (potential) way the server
could download a key or a Credential when authenticating.

https://github.com/bblfish/authentication-panel/blob/HttpSig/HttpSignature.md

This is leading me to think that we could do with a slight alteration to the
Signing-HTTP message spec. Our use case I think justifies it.

Namely: I think it would help if the keyId field of the Signature-Input
header could allow not just opaque tokens to be passed as values but also
relative or absolute URLs. This could be made clear by specifying that
when enclosed with `<` and `>` a URL is intended. In the spec I give
two examples, one of which is

Signature-Input: sig1=(); keyId="</keys/test-key-a>"; created=1402170695
Signature: sig1=:…

the other is

Signature-Input: sig1=(); keyId=”<https://alice.freedombox/keys/test-key-a>"; created=1402170695
Signature: sig1=:…

The advantages of http urls is that they allow the client to create a key using POST or PUT,
edit them with PUT or PATCH and DELETE them, solving the key revocation problem.

Thinking ahead with Cory Benfield’s P2P protocol draft in mind, made consider that we should
keep open the option for relative URLs to be enclosed in `>` and `<` which would be relative URLs
dereferenceable on the client, when it takes on the role of server on the same
connection using something filling in the role of your P2P extension.

Signature-Input: sig1=(); keyId=”>/keychain/test-key-a<"; created=1402170695
Signature: sig1 …

This may not be so useful for keys, but more for passing the certificate once the key
has been verified. (The server could then tie the URL to the key, and perhaps find the
key had been sent in a previous request).

I would also be very interested on feedback on my HTTP Signature for Solid
proposal of course :-)

Henry

> On 27 Jan 2021, at 11:04, Cory Benfield <cory@lukasa.co.uk> wrote:
> 
> 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 <henry.story@bblfish.net> 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: +33 6 38 32 69 84‬
>> Twitter: @bblfish
>> 

Henry Story

https://co-operating.systems
WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
Twitter: @bblfish