Hi Nat,
thanks for the quick response.
I was hoping to see a statement like The code verifier MUST have enough
entropy to make it impractical to guess the value. in the text rather
than the SHOULD. Given all the other statements in the draft I am not
sure what the should actually means. Under
Hi John,
I am fine with the plain vs. SHA256 concept and I understand the
reasoning behind the two. Having the same for both types is also OK for me.
My question about the 32 bytes entropy was based on curiosity. SHA256 is
a function that takes an arbitrary length input and produces an output
Is there anyone who has problems changing it to a MUST?
On 2015年2月18日(水) at 18:48 Hannes Tschofenig hannes.tschofe...@gmx.net
wrote:
I think that the controlled environment is a risky idea. I believe we
should definitely go for a MUST.
On 02/18/2015 10:26 AM, Nat Sakimura wrote:
Hi Hannes,
Hi Hannes,
The reason I have put SHOULD there instead of MUST is
that there may be a valid reason not to in a controlled
environment, and it does not interfere the interoperability.
The deployment may opt to use other control than entropy,
and SHOULD allows it while MUST does not.
Having
I think that the controlled environment is a risky idea. I believe we
should definitely go for a MUST.
On 02/18/2015 10:26 AM, Nat Sakimura wrote:
Hi Hannes,
The reason I have put SHOULD there instead of MUST is
that there may be a valid reason not to in a controlled
environment, and it
I’ll incorporate this feedback into another draft, to be posted by the end of
the week. Thanks everyone!
— Justin
On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
kathleen.moriarty.i...@gmail.com wrote:
On Wed, Feb 18, 2015 at 10:07 AM, John Bradley ve7...@ve7jtb.com
Hi Justin, Hi John,
I believe that provisioning a client with a unique id (which is what a
client id/client secret is) allows some form of linkability. While it
may be possible to associate the client to a specific user I could very
well imagine that the correlation between activities from a user
Kathleen == Kathleen Moriarty kathleen.moriarty.i...@gmail.com writes:
Kathleen registry, but setting HTTP Basic as the default seems like
Kathleen a really bad choice. HOBA is on it's way to becoming an
Kathleen RFC from the HTTPAuth working group. HTTPAuth also has an
Kathleen
It was Google that wanted S256 to be mandatory for the AS to support. That
makes it easier for the client.
S256 is relatively new so not being supported yet is not surprising.
Sent from my iPhone
On Feb 18, 2015, at 12:15 PM, Torsten Lodderstedt tors...@lodderstedt.net
wrote:
We don't
On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman hartmans-i...@mit.edu wrote:
Kathleen == Kathleen Moriarty kathleen.moriarty.i...@gmail.com
writes:
Kathleen registry, but setting HTTP Basic as the default seems like
Kathleen a really bad choice. HOBA is on it's way to becoming an
I was OK with SHOULD because there's no firm measure of enough entropy.
Whether it's SHOULD or MUST is moot without some way to quantify it.
On Wednesday, February 18, 2015 1:27 AM, Nat Sakimura
n-sakim...@nri.co.jp wrote:
Hi Hannes,
The reason I have put SHOULD there instead of
On Wed, Feb 18, 2015 at 7:38 AM, John Bradley ve7...@ve7jtb.com wrote:
I don’t remember precisely , but I may be the one responsible for the for
the 2^(-128) value for code.
The archives have a more precise memory
http://www.ietf.org/mail-archive/web/oauth/current/msg03844.html ;)
As I stated in my message. I think for plain having there be a MUST at 256
bits would be overkill.
For plain given it is single use like the code is we should probably match it
to the entropy required for code.
In RFC 6749 we say
The probability of an attacker guessing generated tokens (and
Hi,
On Mon, Feb 16, 2015 at 6:42 PM, Mike Jones michael.jo...@microsoft.com
wrote:
A few responses and comments are inline below...
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, February 12, 2015 11:47 AM
To: Justin Richer
Cc: oauth@ietf.org
Hi Hannes,
our implementation supports the plain mode only. We just verified
compliance of our implementation with the current spec. As the only
deviation, we do not enforce the minimum length of 43 characters of the
code verifier.
kind regards,
Torsten.
Am 17.02.2015 17:48, schrieb Hannes
I tend to agree with Torsten here - similar sentiments were (maybe not
well) expressed a few weeks ago:
http://www.ietf.org/mail-archive/web/oauth/current/msg14155.html
On Wed, Feb 18, 2015 at 6:36 AM, tors...@lodderstedt.net wrote:
Hi Nat,
as far as I understand, the length of at least 32
Hi,
On Tue, Feb 17, 2015 at 7:03 PM, Phil Hunt phil.h...@oracle.com wrote:
I’m not sure if this is what Kathleen is after. I think part of the
background in the current spec is that we were trying to differentiate from
the large scale success stories OAuth has had in the past like Facebook
Thanks for the info, Torsten.
Your feedback raises an interesting question, namely what functionality
the parties have to implement to claim conformance to the specification.
Quickly scanning through the specification didn't tell me whether it is
OK to just implement the plain mode or whether
snip
On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
kathleen.moriarty.i...@gmail.com wrote:
The client_id *could* be short lived, but they usually aren't. I don't see
any particular logging or tracking concerns using a dynamic OAuth client
above using any other piece of software,
On Wed, Feb 18, 2015 at 10:07 AM, John Bradley ve7...@ve7jtb.com wrote:
snip
On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
kathleen.moriarty.i...@gmail.com wrote:
The client_id *could* be short lived, but they usually aren't. I don't
see any particular logging or tracking concerns using
20 matches
Mail list logo
