Nat - is there cryptanalysis of the proposed model available anyplace?
Extending protocols by throwing in a smidgen of hashing and a tablespoon
of encryption is often a bad idea. One of the strengths of /RFC/ 6749 is
that it avoids stuff like that.
What do you mean when you say -
[quote]
The
AS that don't maintain state would need to encode everything into code. I
have seen a couple of implementations do that. The encoding tends to be
custom for size reasons.
Many AS maintain server state for code as it also has grants, redirect_uri,
client_id, subject etc that need to be tracke
FWIW, this was raised before in 2011.
http://www.ietf.org/mail-archive/web/oauth/current/msg06073.html
http://www.ietf.org/mail-archive/web/oauth/current/msg06079.html
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-09-02, at 3:44 PM, John Bradley wrote:
> AS that
Yes Phil it is the same sort of idea that you proposed in 2011.
In this proposal it is limited to preventing an attacker who intercepts code
from being able to use it even if it knows the client_id and secret of the
requester as is likely in a native app without dynamic registration case.
I thi
