Perfect! Thank you! A couple comments on version 01...
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
(remainder of JWK omitted for brevity)
I believe the "(remainder of JWK..." should be moved to the DPoP-Binding
header...
Also, there is no discussion of the DPoP-Binding header outside of the
token request, but I suspect that is the desired way to communicate the
DPoP-Proof to the RS.
Possibly an example in the session for presenting the token to the RS
would help.
Thanks,
George
On 4/3/19 11:39 AM, Daniel Fett wrote:
This is fixed in -01:
https://tools.ietf.org/html/draft-fett-oauth-dpop-01
-Daniel
Am 03.04.19 um 17:28 schrieb George Fletcher:
A quick question regarding...
o "http_uri": The HTTP URI used for the request, without query and
fragment parts (REQUIRED).
Is 'without' supposed to be 'with' ? The example shows the http_uri
*with* the query parameters :)
On 3/28/19 6:17 AM, Daniel Fett wrote:
Hi all,
I published the first version of the DPoP draft at
https://tools.ietf.org/html/draft-fett-oauth-dpop-00
Abstract
This document defines a sender-constraint mechanism for OAuth 2.0
access tokens and refresh tokens utilizing an application-level
proof-of-possession mechanism based on public/private key pairs.
Thanks for the feedback I received so far from John, Mike, Torsten,
and others during today's session or before!
If you find any errors I would welcome if you open an issue in the
GitHub repository at https://github.com/webhamster/draft-dpop
- Daniel
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
