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
The issue for any service is that things like gateways and proxies may change
or add parameters.
There is a long tradition with http to mess with things headers and payload in
the real world. Not ideal, but a certain reality.
Thus for certain services it is likely only possible to sign a subse
Being able to selectively include or exclude individual query string name=value
parameters in a signature feels far too dangerous. Always sign them all — with
the only exception being the signature itself if transmitted as a query string
parameter.
Unfortunately we do need to selectively include
Yea, I’m cool with just saying “duplicate keys won’t work” for my
implementation, unless I do some implementation specific thing like sort them
by value order or some such (but that would have to be on both sides).
-Brock
From: Justin Richer [mailto:jric...@mit.edu]
Sent: Sunday, Februar
Yeah, that’s the trick — you don’t want to end up replicating the entire HTTP
message inside the JWS envelope, because then you end up with a SOAP kind of
approach where you’re not really using the outside HTTP constructs to their
fullest anymore.
In the end, I don’t think this spec is ever go
Now that I’m thinking about this, the only thing that comes to mind is a hash
of the value included somehow (which I’m sure you’ve already thought of).
That’s obviously more complexity and overhead for all scenarios to support this
edge case.
-Brock
From: Brock Allen [mailto:brockal...@
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
Ok, missed that – thanks.
For now in my implementation I’m also ignoring this problem :)
-Brock
From: Justin Richer [mailto:jric...@mit.edu]
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen
Cc:
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
In
In §7.5 we currently have:
The behavior of repeated query parameters or repeated HTTP headers is
undefined by this specification. If a header or query parameter is
repeated on either the outgoing request from the client or the
incoming request to the protected resource, that query par
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
Given that the client can iterate over the query/headers in any order to
generate the concatenated value to hash, I think there's an issue with query
string or header values with repeated keys. I'll stick with query params for
simplicity in my sample.
If a client signs this concatenated query:
Hi Thomas,
see comments inline.
Am 19.02.2016 um 12:14 schrieb thomas.ku...@bmw.de:
Hi,
we use the OAuth 2.0 Implicit grant to issue access_tokens to client
applications such as HTML 5 web apps that have no secure means to
securely authenticating themselves. Even if the credentials would be
Hi all,
I prefer to use draft-jones-oauth-mix-up-mitigation-01 as starting point
simply because it gives some description of the threats we need to cope
with. This does not preclude to eventually use
draft-sakimura-oauth-meta-07 as solution or any other suitable
mechanisms we find consensus o
14 matches
Mail list logo
