Finally, we added PKCE S256 support on our implementation.
Best,
Nat
2015年2月20日(金)、7:28 Brian Campbell :
> I can't comment with any authority on product road-map (that's above my
> pay-grade) but I can speculate that we probably would support "S256"
> eventually.
>
> On Wed, Feb 18, 2015 at 10:3
I can't comment with any authority on product road-map (that's above my
pay-grade) but I can speculate that we probably would support "S256"
eventually.
On Wed, Feb 18, 2015 at 10:33 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Thanks Brian for pointing me to Section 4.4.1 and to t
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
> wrote:
>
> We don't plan to support s25
We don't plan to support s256
Basically, I don't see a need to. Plain already mitigates the threat, spop/tcse
had been designed to mitigate - an app intercepting the code response of a
public client.
Am 18. Februar 2015 18:33:17 MEZ, schrieb Hannes Tschofenig
:
>Thanks Brian for pointing me t
Thanks Brian for pointing me to Section 4.4.1 and to the MTI for "S256".
While this is good from a security point of view I am wondering whether
anyone is actually compliant to the specification. Neither PingIdentity
nor DT implements the S256 transform, if I understood that correctly.
Are you guys
There's a bit of MTI talk tucked into
https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that
perhaps needs to be expanded and/or placed somewhere else.
On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Thanks for the info, Torsten.
>
> Your
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 bot
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 Hanne
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
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 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
Deutsche Telekom also implemented an early version of the draft last year.
> Am 30.01.2015 um 18:50 schrieb Brian Campbell :
>
>
>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>> wrote:
>>
>> 1) What implementations of the spec are you aware of?
>
> We have an AS side implementation
On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
>
> 1) What implementations of the spec are you aware of?
>
We have an AS side implementation of an earlier draft that was released in
June of last year:
http://documentation.pingidentity.com/pages/viewpage.act
13 matches
Mail list logo
