+1 to adopt.
I don't think we're planning to use this, but it looks useful and doesn't
harm interoperability so I support it.
On Sat, Feb 6, 2016 at 3:43 AM, Torsten Lodderstedt wrote:
> +1
>
>
> Am 04.02.2016 um 17:37 schrieb John Bradley:
>
>> I support it.
>>
>> I have always thought of this
I think Toresen states it well.
The reason we looked at 2 again is that #1 in some of the attacks was being
used to leak the code.
In some of those cases the attacker had the client credentials and could use
the directly to get access tokens.
In other cases the attacker doesn’t have the clien
Dynamic client registration makes provisioning secrets much easier on
devices like this. When it was originally written, the target was a
public native application, where every copy would've gotten the same
secret at manufacture time rendering it not as secret. We've got good
ways around that r
+1
Am 04.02.2016 um 17:37 schrieb John Bradley:
I support it.
I have always thought of this as informational. It is not the only way to do
it, and has no real interoperability impact.
John B.
On Feb 4, 2016, at 3:29 AM, Mike Jones wrote:
I support adoption of this document by the working
I support adoption of this draft as starting point.
I would like to note the following:
- this flow is vulnerable to session fixation - A discussion of this
threat along with a reasonable mitigation needs to be added.
- I dont't understand why this particular flow precludes use of client
secret
Hi Hannes,
#2 is not directly described in the paper but was used to replay the
code/token the attacker obtained via #1. In my observation, the
discussion in Darmstadt has shown that OAuth (and its built-in
mitigations) so far focused on preventing code/token leakage but we lake
mitigation fo
I think the service discovery document (describing all the endpoints and
features of the AS) is a valid starting point. That's basically how we
use the OIDC discovery in the OAuth context today at DT. We refer
partners to the openid-configuration document. Putting the data relevant
to OAuth und
