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
+1 for “OAuth 2.0 Authorization Server Discovery”
— Justin
> On Feb 25, 2016, at 2:20 PM, George Fletcher wrote:
>
> +1 for “OAuth 2.0 Authorization Server Discovery”
>
> On 2/25/16 2:10 PM, Mike Jones wrote:
>> Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept
>> your
My preference is for Option A.
The mix-up attack, in all it's variations, relies on there being no means
in OAuth for the AS to identify itself to the client when it returns the
user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up Mitigation'
addresses that fundamental missing piece by i
As long as the "aud" value is more akin to a fixed URI from which the
client can determine valid endpoints for that "aud", this could work. It
does make the client do a lot of discovery.
I don't think the "aud" value can be a domain.
Thanks,
George
On 2/26/16 12:52 AM, nov matake wrote:
It so
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
A given AS may be supporting different protocols and or scopes with different
privileges.
Those would need to be mapped into where the token can be used.
If we try to use audience only to stop cross RS replay it will in my opinion
become hopelessly complex.
I think the only secure and practic
