+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
Hi Phil,
Hi Blair,
this is a good point. I also don't see a reason why the HTTP protocol
version should be included in the keyed message digest (from a security
point of view).
It might, however, be worthwhile to point out that we are exploring
different solution directions, as described in this
Conceptually, draft-cavage-http-signatures-02 is the same as OAuth 1.0.
Therefore, the symmetric key part of the document is the same as the MAC
token.
Not quite sure why the authors have not read the OAuth work.
On 05/09/2014 01:22 AM, Phil Hunt wrote:
> How does this compare with justin's draft
