2014/11/14 14:13、John Bradley のメール：
> 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 the article, the
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
value
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 wrote:
> There's a draft it would be great to get more eyes on in the Kitten WG
>
> draft-ietf-kitten-sasl-oauth-17 - A se
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/oaut
Yep, fair enough. Done.
On Friday, November 14, 2014 6:33 AM, Brian Campbell
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 Mills wrote:
There's a draf
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. B
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 e
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 to
I find not much, if any.
On Fri, Nov 14, 2014 at 06:27 Brian Campbell
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 code_challenge_method
> using browser redirects? Especially
Sounds good.
On Fri, Nov 14, 2014 at 05:29 Brian Campbell
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..."
> ___
Nat and I discussed it yesterday and I am still personally unconvinced
that the errors from the authorization endpoint are helpful. So I am
personally against adding specific errors for S256_unsupported
On Nov 14, 2014, at 6:52 AM, Nat Sakimura wrote:
> I find not much, if any.
>
>
> On
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 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) structured client_
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 [m
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 wrote:
> Nat and I discussed it yesterday and I am still pe
I sent some feedback on that section in a different message on list.
On Friday, November 14, 2014 12:41 PM, Nat Sakimura
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 error response but
Thanks. I will dig it up.
On Fri, Nov 14, 2014 at 10:54 Bill Mills wrote:
> I sent some feedback on that section in a different message on list.
>
>
> On Friday, November 14, 2014 12:41 PM, Nat Sakimura
> wrote:
>
>
> That pretty much was the conclusion we reached. I believe that it was what
>
-Original Message-
From: "oauth-requ...@ietf.org"
Sent: 11/14/2014 2:54 PM
To: "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, visit
https://www.ietf.o
-Original Message-
From: "oauth-requ...@ietf.org"
Sent: 11/14/2014 2:03 PM
To: "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, visit
https://www.ietf.o
-Original Message-
From: "oauth-requ...@ietf.org"
Sent: 11/15/2014 12:50 AM
To: "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 Web, visit
https://www.ietf.
Message Me 6127607882 It's C.-W.
-Original Message-
From: "oauth-requ...@ietf.org"
Sent: 11/14/2014 11:07 AM
To: "oauth@ietf.org"
Subject: OAuth Digest, Vol 73, Issue 36
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide Web,
20 matches
Mail list logo
