My understanding:
The proof-of-possession needs to have a limited destination to prevent replay
against other resources. Similar to resource indicators and to distributed
OAuth, the client is expected to use a resource URL view of the world rather
than an access-token-specific audience or scope
Then why include the request at all? Simpler to just sign a nonce and send
those, then.
— Justin
On Apr 9, 2019, at 7:05 PM, Brian Campbell
mailto:bcampb...@pingidentity.com>> wrote:
The thought/intent is that it's really about proof-of-possession rather than
protecting the request. So the si
The thought/intent is that it's really about proof-of-possession rather
than protecting the request. So the signature is over a minimal set of
information.
On Mon, Apr 8, 2019 at 5:41 PM Justin Richer wrote:
> Corollary to this, are there thoughts of header protection under this
> method, and th
Corollary to this, are there thoughts of header protection under this method,
and the associated issue of header modification?
— Justin
On Apr 8, 2019, at 7:23 PM, Phil Hunt
mailto:phil.h...@oracle.com>> wrote:
Question. One of the issues that Justin Richer’s signing draft tried to address
wa
Question. One of the issues that Justin Richer’s signing draft tried to address
was url modification by tls terminators/load balencers/proxies/api gateways
etc.
How do you see this issue in dpop? Is it a problem?
Phil
> On Apr 3, 2019, at 9:01 AM, George Fletcher
> wrote:
>
> Perfect! Tha
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=
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
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 publish
On 02/04/2019 17:35, Brian Campbell wrote:
Except that the jwk header is more appropriate in the given context
https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key
that corresponds to the key used to digitally sign the JWS. Which is
what it is.
A quick nit:
i
ion, Ludwig. We should do that.
>
> -- Mike
>
> -Original Message-
> From: OAuth On Behalf Of Ludwig Seitz
> Sent: Thursday, March 28, 2019 12:05 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
>
> On 28
ially addresses many of the security
requirements
that OAuth 2.0 does not currently provide.
Thanks,
Rich Levinson
Re: [OAUTH-WG] draft-fett-oauth-dpop-00
Filip Skokan Fri, 29 March 2019 16:39 UTCShow header
<https://mailarchive.ietf.org/arch/browse/oauth/#>
And here's a
And here's a real simple client-side implementation using
- Webcrypto API
- IndexedDB API
- fetch
https://boiling-escarpment-16732.herokuapp.com/
It's not really a SPA but uses the same browser APIs and no backend other
than a web server hosting the html.
Best,
*Filip Skokan*
On Thu, 28 Mar 2
Hello Daniel, everyone,
I've hacked together an AS implementation to enable client-side
experimentation using this draft.
You can find this hosted at
https://draft-fett-oauth-dpop-00.herokuapp.com (it's
also the issuer identifier). There's a default client registered and
dynamic registration is a
Good observation, Ludwig. We should do that.
-- Mike
-Original Message-
From: OAuth On Behalf Of Ludwig Seitz
Sent: Thursday, March 28, 2019 12:05 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
On 28/03/2019 11:17, Daniel Fett
On 28/03/2019 11:17, 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
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
16 matches
Mail list logo
