Hi
On 06/09/13 00:44, John Bradley wrote:
At this point we don't know of any attack against the request, however
that is not guaranteed to remain the case.
If we send the secret in plain text through the browser it likely will
never get IETF acceptance.
We use HMAC a fair bit already I don't
: oauth
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
draft-sakimura-oauth-tcse-00.txt
At this point we don't know of any attack against the request, however that is
not guaranteed to remain the case.
If we send the secret in plain text through the browser it likely will never
get IETF
Depending on the level of assurance that you might want to achieve, it
could have been a random string. That's how some of the existing but widely
deployed implementations are doing.
I have taken a step forward to do the hashing to give a little more
protection that even if a malware on the
At this point we don't know of any attack against the request, however that is
not guaranteed to remain the case.
If we send the secret in plain text through the browser it likely will never
get IETF acceptance.
We use HMAC a fair bit already I don't think that would be a significant
From the security PoV, I prefer HMAC as well.
If implementers supports the idea, I would change it to HMAC in the next
rev.
I am also open to changing the param names. As I was writing them, I was
reading JWx specs and got influenced by their short names apparently. I
have no strong preference.
I
How about request identifier?
Phil
On 2013-09-03, at 23:04, Nat Sakimura sakim...@gmail.com wrote:
From the security PoV, I prefer HMAC as well.
If implementers supports the idea, I would change it to HMAC in the next rev.
I am also open to changing the param names. As I was writing them,
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]
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
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 ve7...@ve7jtb.com
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
@ietf.orgmailto:oauth@ietf.org
Subject: [OAUTH-WG] Fwd: New Version Notification for
draft-sakimura-oauth-tcse-00.txt
As some of you know, passing the authorization code securely to a native app on
iOS platform is next to impossible. Malicious application may register the same
custom scheme as the victim
As some of you know, passing the authorization code securely to a native
app on iOS platform is next to impossible. Malicious application may
register the same custom scheme as the victim application and hope to
obtain the code, whose success rate is rather high.
We have discussed about it during
12 matches
Mail list logo
