Re: setting headers in JS for HTTP Signature

> On 9 Nov 2015, at 19:02, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> On 2015-11-09 19:32, henry.story@bblfish.net wrote:
>> 
>>> On 8 Nov 2015, at 11:17, henry.story@bblfish.net wrote:
>>> 
>>> I have opened an issue on the whatwg Fetch issues list to see if
>>> they can add a function to allow one to access the headers before
>>> they get sent, so that one could actually sign as many of the
>>> headers possible.
>>> 
>>> https://github.com/whatwg/fetch/issues/156
>> 
>> On irc annevk wrote (unofficially I suppose):
>> 
>>> yeah I looked at that and that doesn't seem like something we'll address anytime soon
>>> the headers to be transmitted are in the network stack which is mostly post-Fetch
>>> although it's all a bit gobbled up admittedly since the standards are a bit post-implementation
>> 
>> That's not that surprising.
>> 
>> So as we can't get the Date or things that may play the role of a nonce, what do we do?
>> 
>> WebID-RSA ( https://github.com/solid/solid-spec#webid-rsa ) has the server send a nonce. Though I am not sure how the server would remember which nonce was sent. Also the
>> lack of a date seems to make it open to replay attacks. ( which is why having access to the date in the Signature is quite important. )
>> 
>> With HTTP Signatures we can get something like the WebID by passing a User header with the WebID. But we'd need to find a way to add an extra date header, which I suppose should never be
>> more than a few seconds out of sync with the real date header.
>> 
>> Any ideas?
> 
> Forgive my ignorance but I don't understand the problem.
> 
> Since SOP is ruling, I don't see how you could get hold of the WebID in the first place
> unless it is the origin site requesting (which already should know about it).

You can have your JS crypto sign headers that go to other origins.  ( I am pretty sure of this now, but I am waiting to have implemented to declare victory officially )

You can't share keys between origins using the WebCrypto API, and so JS coming from two origins would need different keys. But this is similar to the problem you have with FIDO, where if you have two devices you need another way  of tying those two devices to the same identity ( since those devices can't share keys)

It would be a nice feature to be able to have JS from different origins be also able to use the same keys ( via a user selection interface ). I'll consider that later. But we can get some leverage as things stand now.

Henry

> 
> Anders
> 
>> 
>> 
>> annevk also wrote ( first impression - but its always interesting to collect those )
>>> That draft seems to sorta skip over justification for why it's a good idea to begin with
>> 
>> Anyway, he's thinking about it. But even if they do advance we'd need something we can use now.
>> 
>> 
>> Henry
>> 
>> 
>

Received on Monday, 9 November 2015 19:09:17 UTC