2014/11/14 14:13、John Bradley ve7...@ve7jtb.com のメール：
This blog post has some good background on why salting is no longer effective
against brute force attacks.
http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html?m=1
It is basic knowledge as you know.
If I don’t misunderstand
My question was not really about the status of
draft-bradley-oauth-stateless-client-id but rather about
draft-ietf-oauth-dyn-reg-management allowing for the kind of stateless
client id that Bradley described in his draft.
And draft-ietf-oauth-dyn-reg-management still has text that says, 'The
Given the state of things, maybe the MAC Token specification
[I-D.ietf-oauth-v2-http-mac] reference should be changed or omitted?
On Thu, Nov 13, 2014 at 7:01 PM, Bill Mills wmills_92...@yahoo.com wrote:
There's a draft it would be great to get more eyes on in the Kitten WG
In the into, I'd suggest changing,
The code verifier is created for every authorization request...
to
A unique code verifier is created for every authorization request...
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Yep, fair enough. Done.
On Friday, November 14, 2014 6:33 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
Given the state of things, maybe the MAC Token specification
[I-D.ietf-oauth-v2-http-mac] reference should be changed or omitted?
On Thu, Nov 13, 2014 at 7:01 PM, Bill
The code challenge is only one time use and has a short validity period. It
is not something that is going to be stored.
For (1), we could define such transformation, but at a later time, IMHO. We
are getting push back even for sha256 from developers. We need to balance
the benefit and adoption.
I struggle to see the value in adding more fine grained machine readable
error messages for this.
Do we really want clients to try and negotiate the code_challenge_method
using browser redirects? Especially in light of the fact that we'll likely
also be discouraging AS's from redirecting on some
Brian is right, it's still a MUST NOT. We could relax that to a SHOULD NOT to
allow for the (still largely theoretical) structured client_id construct to
change over time. The reason it's how it is right now is that most systems use
the client_id value as a key into things and funny expect it
editorhatoffI find not much, if any. /editorhatoff
On Fri, Nov 14, 2014 at 06:27 Brian Campbell bcampb...@pingidentity.com
wrote:
I struggle to see the value in adding more fine grained machine readable
error messages for this.
Do we really want clients to try and negotiate the
Sounds good.
On Fri, Nov 14, 2014 at 05:29 Brian Campbell bcampb...@pingidentity.com
wrote:
In the into, I'd suggest changing,
The code verifier is created for every authorization request...
to
A unique code verifier is created for every authorization request...
I'd guess people wouldn't try to deploy those two options together because
it's clearly prohibited.
On Fri, Nov 14, 2014 at 9:47 AM, Justin Richer jric...@mit.edu wrote:
Brian is right, it's still a MUST NOT. We could relax that to a SHOULD NOT
to allow for the (still largely theoretical)
Please change jwt-req-request to jwt-reg-review, per
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-30#section-10.1.
Other than that, the minutes look good.
Thanks,
-- Mike
-Original Message-
From: OAuth
That pretty much was the conclusion we reached. I believe that it was what
the F2F room inclined to. So, for -04, we added a section on error response
but it doesn't have those granular errors.
On Fri, Nov 14, 2014 at 07:07 John Bradley ve7...@ve7jtb.com wrote:
hatoff Nat and I discussed it
I sent some feedback on that section in a different message on list.
On Friday, November 14, 2014 12:41 PM, Nat Sakimura sakim...@gmail.com
wrote:
That pretty much was the conclusion we reached. I believe that it was what the
F2F room inclined to. So, for -04, we added a section on
Thanks. I will dig it up.
On Fri, Nov 14, 2014 at 10:54 Bill Mills wmills_92...@yahoo.com wrote:
I sent some feedback on that section in a different message on list.
On Friday, November 14, 2014 12:41 PM, Nat Sakimura sakim...@gmail.com
wrote:
That pretty much was the conclusion we
-Original Message-
From: oauth-requ...@ietf.org oauth-requ...@ietf.org
Sent: 11/14/2014 2:54 PM
To: oauth@ietf.org oauth@ietf.org
Subject: OAuth Digest, Vol 73, Issue 38
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide Web,
-Original Message-
From: oauth-requ...@ietf.org oauth-requ...@ietf.org
Sent: 11/14/2014 2:03 PM
To: oauth@ietf.org oauth@ietf.org
Subject: OAuth Digest, Vol 73, Issue 37
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide Web,
-Original Message-
From: oauth-requ...@ietf.org oauth-requ...@ietf.org
Sent: 11/15/2014 12:50 AM
To: oauth@ietf.org oauth@ietf.org
Subject: OAuth Digest, Vol 73, Issue 39
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide
Message Me 6127607882 It's C.-W.
-Original Message-
From: oauth-requ...@ietf.org oauth-requ...@ietf.org
Sent: 11/14/2014 11:07 AM
To: oauth@ietf.org oauth@ietf.org
Subject: OAuth Digest, Vol 73, Issue 36
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or
19 matches
Mail list logo
