I'd say it should be a MUST so that implementations are consistent about it.
On Fri, May 16, 2014 at 3:27 PM, Bill Mills wrote:
> The HTTP specs don't limit these things, but implementations do, and the
> problems when you run into them are a rea pain.
>
> DO we want to make this a hard limit,
The HTTP specs don't limit these things, but implementations do, and the
problems when you run into them are a rea pain.
DO we want to make this a hard limit, or should it be guidance in the form of
RECOMMENDED or SHOULD?
On Friday, May 16, 2014 9:35 AM, Brian Campbell
wrote:
Yeah, I agree
Yeah, I agree with John here. There are a few good reasons to restrict the
length of the code_challenge. One is trying to keep the authorization
request URI to reasonable size as it will eventually run into various
limits on clients and/or servers. The other is constraining the amount of
data that
From the AS side you probably want to know what the max size you need to store
per code.
On the call to the token endpoint it is a POST so size should not be an issue.
On May 16, 2014, at 3:10 PM, Nat Sakimura wrote:
> Now that I cannot remember what limit we were hitting, it might be a goo
Now that I cannot remember what limit we were hitting, it might be a good
idea to remove the constraint and see if anyone protests.
What do you think?
Nat
2014-05-14 20:46 GMT+09:00 Brian Campbell :
> That too would suggest that the length limit be on code_challenge because
> that's the parame
That too would suggest that the length limit be on code_challenge because
that's the parameter that will be on URIs getting passed around. The
code_verifier is sent directly in the POST body from client to AS.
On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrote:
> +1 for octet. We used to have
+1 for octet. We used to have "bytes" in JW* so I used "bytes" here, while
at the same time complaining in Jose that it should be "octet". JW* changed
to "octet" but I failed to sync with it in the last few edits.
I do not quite remember which platform, but the reason for the limit was
that some p
And it'd give the AS some direct guidance on protecting itself from crazy
long code_challenge values rather than relying on the client not to do
something creative.
On Mon, May 12, 2014 at 3:54 PM, Brian Campbell
wrote:
> Right but that's why I'm asking why not just put the limit on
> code_chall
Right but that's why I'm asking why not just put the limit on
code_challange rather than inferring it from code_verifyer + challenge
algorithm, which probably bounds it but doesn't necessarily do so? It's not
a big deal but would read more clearly, I think.
On Mon, May 12, 2014 at 3:48 PM, John B
Yeah, it does depend on what it really is and why the length needs to be
restricted. That's what the other questions were really about.
Octets would be better than bytes, if that's what's intended.
On Mon, May 12, 2014 at 3:15 PM, Derek Atkins wrote:
> Brian Campbell writes:
>
> > I notice th
I think octets is more consistent with other JW* and OAuth specs.
The code_challange is the same length as the code_verifyer or is a hash of the
code_verifyer so likely smaller than 128octets (43 ish for base64 256 bit)
Limiting the code_verifyer size sets the upper bound for code_challange, unl
Brian Campbell writes:
> I notice that code_verifier is defined as "high entropy cryptographic random
> string of length less than 128 bytes" [1], which brought a few questions and
> comments to mind. So here goes:
>
> Talking about the length of a string in terms of bytes is always potentially
12 matches
Mail list logo
