-Original Message-
From: "oauth-requ...@ietf.org"
Sent: 11/19/2014 11:54 PM
To: "oauth@ietf.org"
Subject: OAuth Digest, Vol 73, Issue 54
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.
-Original Message-
From: "oauth-requ...@ietf.org"
Sent: 11/19/2014 6:44 AM
To: "oauth@ietf.org"
Subject: OAuth Digest, Vol 73, Issue 51
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/19/2014 7:47 AM
To: "oauth@ietf.org"
Subject: OAuth Digest, Vol 73, Issue 52
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/19/2014 8:56 AM
To: "oauth@ietf.org"
Subject: OAuth Digest, Vol 73, Issue 53
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.o
Hi,
I reviewed draft-Ietf-oauth-dyn-reg-20 and have the following questions before
we move this to IETF last call.
Sect 2, Has there been any consideration in the WG of using alternate auth
methods from HTTPAuth like HOBA? I realize this is referencing Oauth defined
methods from the framework
From: Mike Jones
Sent: Wednesday, November 19, 2014 5:22 PM
To: j...@ietf.org
Cc: Pete Resnick; Stephen Farrell; Richard Barnes
Subject: JOSE -37 and JWT -31 drafts addressing remaining IESG review comments
These JOSE and JWT drafts contain updates intended to address the remaining
outstanding
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : JSON Web Token (JWT)
Authors : Michael B. Jones
John Bradley
On 2014/11/19, at 18:01, Sergey Beryozkin wrote:
> Hi
>
> Apologies for getting into this thread (I do not understand most of the
> mathematics at this stage :)),
> On 19/11/14 06:43, takamichi saito wrote:
>> (2014/11/18 13:54), Bill Mills wrote:
>>> There will be no rainbow table for 256bits
On 2014/11/18, at 17:08, Nat Sakimura wrote:
> The code verifier is 256 bit high entropy cryptographic random.
>
> Let D:= {d | all possible 256 bit random}. This is the set of all possible
> code verifiers.
> Let S be SHA256 function.
> Then, set of all possible code challenge corresponding
Hi John
Thanks for going over it again and explaining it all so nicely, even I
do understand it now (I'd like to think so :-)) why using a client id as
a salt does not add much to the signature strength.
I thought the idea was consider to introduce some extra randomization,
where say even mult
Hannes,
Thanks for the feedback. I will go over it today.
> On Nov 19, 2014, at 7:44 AM, Hannes Tschofenig
> wrote:
>
> Hi Nat,
>
> I have a few text suggestions for the abstract and the intro.
>
>
> FROM:
>
> Abstract
>
> The OAuth 2.0 public client utilizing Authorization Code Gran
Hi Nat,
I have a few text suggestions for the abstract and the intro.
FROM:
Abstract
The OAuth 2.0 public client utilizing Authorization Code Grant (RFC
6749 - 4.1) is susceptible to the code interception attack. This
specification describes a mechanism that acts as a control against
Hi Sergey,
If we change from a SHA256 function over the code_verifier to a SHA256 over the
concatenation of the code_verifier and client_id, that would be defined in the
spec.
We would not do both, and the salt would not be a real random. There would be
many instances of a client all using th
Hi Mike, Hi Brian,
I have updated the meeting minutes based on your requests.
Here is the updated version:
http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth
Ciao
Hannes
On 11/14/2014 08:43 PM, Mike Jones wrote:
> Please change "jwt-req-request" to "jwt-reg-review", per
> https://tool
Yes, S() is surjection. Specifically, it is defined over X:={x | len(x) =<
2^64 -1}, and the range is R. R is included in X. However, in SPOP's case,
the Domain is constrained to D, which is equal to R. That's what I was
explaining. Then, I have defined a rainbow table T:D->R and demonstrated
that
Hi
Apologies for getting into this thread (I do not understand most of the
mathematics at this stage :)),
On 19/11/14 06:43, takamichi saito wrote:
(2014/11/18 13:54), Bill Mills wrote:
There will be no rainbow table for 256bits of search space. Suppose
then that clientID has 256 possible va
16 matches
Mail list logo
