As many of you know, Annabelle and I have put forward a general-purpose HTTP
Signing specification in the HTTP Working Group, at least initially based on
the old Cavage signatures spec that’s been used in the wild. We expect a number
of important changes to happen as it goes through the standard
That document has been brought up and discussed several times in the past in
relation to our own signing mechanism, and it’s been rejected each time. It has
its benefits and drawbacks, as does the signature method that was proposed in
draft-ietf-oauth-http-signing. The biggest drawback of the ca
Hi all,
I met Manu after the OAuth meeting on Monday and he pointed me to his
work on HTTP signing, as described in this document:
https://tools.ietf.org/html/draft-cavage-http-signatures-06
I believe there is some synergy of work going on elsewhere in the IETF.
Since we have had challenges with
To me it seems reasonable that a client may send multiple signed messages
in one second.
So I´m +1 for a nonce. A more fine grained timestamp is nice but I think we
might end upp at the same place, someone saying that they think it is
reasonable to send multiple signed messages the same millisecon
It’s a bit of both and it’s going to be highly specific to the API being
protected. The RS should reject a signed request in which a critical parameter
is unsigned — some implementations of OpenID 2.0 were susceptible to exactly
this kind of attack a number of years ago.
We could probably add
Another question related to HTTP signing.
It's not clear to me from the RFC if the resource server should be using the
incoming pop token JWS to know what to verify, or if the resource server
should have a preconceived notion of what should be sent in the pop token.
For example, the query param
I understand how they work, I’ve built exactly that cache before. But I
askWouldn’t a unique timestamp have the same effect? Currently it’s integer
seconds but slicing that down further (floating point seconds?) if people
desired would allow for multiple signed messages in the same second from t
The nonce would allow to build a replay cache, the timestamp to trim that cache
and reject messages that are too old.
Similar protocols have a nonce for the above reasons (ws-sec msg security,
hawk)...
—
cheers
Dominick Baier
On 27 February 2016 at 03:48:00, Justin Richer (jric...@mit.edu) wr
I’d be glad to add in a nonce if there’s a compelling reason for it, such as
closing a security attack vector.
What’s the proposed purpose of the nonce? Is it just to add randomness to the
signing base? Or is it to prevent replay at the RS? If the former, the
timestamp should add enough of that
Question about the HTTP signing spec - why is there no nonce (and just a
timestamp)?
TIA
-Brock
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
In section 3.2 under calculating header list hash, there's an example of
hashed headers. For the values:
content-type: application/json
etag: 742-3u8f34-3r2nvv3
this is shown as the example:
"h": [["content-type", "etag"],
"bZA981YJBrPlIzOvplbu3e7ueREXXr38vSkxIBYOaxI"]
I believe th
11 matches
Mail list logo
