Hi Torsten,
does this mean that your implementation is not compliant with the
current version anymore or that you haven't had time to verify whether
there are differences to the earlier version?
Ciao
Hannes
On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
> Deutsche Telekom also implemented a
Hi Brian,
what is different between the version you guys implemented and the
version that is currently documented in the latest version of the draft?
Ciao
Hannes
On 01/30/2015 06:50 PM, Brian Campbell wrote:
>
> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
> mailto:hannes.tschofe...@gmx.
Hi Nat, John, Naveen,
thanks a lot for your work on the document.
I still need responses to this mail to complete the shepherd writeup:
http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
I definitely need the IPR confirmation.
It would also be helpful to have someone who implement
When we did the implementation there was no S256 transformation defined or
made MTI for the server. I'm pretty sure it was http://tools.ietf.org/html/
draft-sakimura-oauth-tcse-03
Thus, our server supports only the "no transformation" (as it was called
then) or the "plain" code_challenge_method (a
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 and Google. When
you are a developer trying to build a client for IMAP, a stand
Hi Hannes,
I hereby confirm that I have submit the draft in full conformance with the
provisions of BCP 78 and BCP 79.
Re: Security Consideration (7.1) and section 4.1
The first part of the 7.1 is a non-normative prose explaining that the
implementers got to make sure that the code verifier
I hereby confirm that I have submit the draft in full conformance with the
provisions of BCP 78 and BCP 79.
smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
We have discussed on the list making allowing the entropy for plain to be
smaller.
32bytes was selected as a good value for S256.
The reason for S256 vs plain is that you are assuming an attacker is going to
intercept the request, and thus you want to have enough entropy to prevent
offline b
