Speaking for myself, as a long time user of OAuth 2.0, I am very enthusiastic
about the new proposal:
"OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer"
https://tools.ietf.org/html/draft-fett-oauth-dpop-00
I believe it represents a real milestone for OAuth in that it appears to me
to be the first proposal that is capable of offering true end-to-end integrity
by using the OAuth 2.0 protocol at the application layer.
In addition to the basic proof of possession capability, it inherently contains
the mechanism for the client to completely protect any request that can be
decomposed into a set of key:value pairs, which can then be signed within a JWT.
The additional key:value pairs can be included in a Resource Access POST
request,
as described in section 5, by placing them in a 2nd JWT using the same public
key
and format as Figure 3, in a parameter with a name required by the Resource
Server Application, for example, "dpop_appl_request".
Since the parameter will be in the body of a POST request, there should be no
size
limitation for the set of key:value pairs that can be provided.
Furthermore, the Access Token received in response to the token request shown
in Figure 3, should cover the "dpop_appl_request" parameter, in the same way
it covers the "dpop_proof" parameter described in section 5, because it covers
the usage of the public key, and any specific content that is protected by that
public key.
The Access Token implicitly contains the user consent, the authorization of the
IdP,
plus the public key of the client making the request, and therefore the
"dpop_appl_request"
can potentially be usable to preserve the signature and possibly be used in
some cases
for non-repudiation, a capability that is not possible using the transport
layer protocols,
which remove all the protocol protection before delivering the request to the
Resource Server Appl.
In summary, the dpop at the appl layer proposal, imo, represents a significant
advance in
OAuth 2.0 technology that potentially 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 <panva...@gmail.com>Fri, 29 March 2019 16:39 UTCShow header
<https://mailarchive.ietf.org/arch/browse/oauth/#>
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 2019 at 19:48, Filip Skokan <panva...@gmail.com>
<mailto:panva...@gmail.com>>; wrote:
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
<https://draft-fett-oauth-dpop-00.herokuapp.com/> (it's
also the issuer identifier). There's a default client registered and
dynamic registration is also open, so hack away. It's using the draft
version with dpop_binding expecting "jwk": { ...jwk } rather then "cnf": {
"dpop+jwk": { ... jwk } } as the payload claim as suggested by Ludwig.
There are more notes on the index page itself.
Aaron kindly accepted to work on the SPA client-side demonstration, I'm
not a SPA guru mastermind like Aaron and it would take me ages to deliver
that particular piece. That being said I did test this with a regular web
app as well as a CLI client using both code+pkce and dynamic port binding
as well as device authorization grant client. Works.
Feeding back to the draft
- i think we should mention the client to provide reasonable
expiration value of the dpop JWTs (max minutes). Altho not critical since
we require a jti, as an AS i don't wanna cache the used jti values forever
:)
- the AS should error when the dpop JWT contains private key material
- altho implied by the use of "public" and "private" key i think it
wouldn't hurt explicitly forbidding "oct" JWKs
- i don't see a point in dpop_proof containing the JWK again unless
the AS is supposed to do something new with it
- it wouldn't hurt mentioning that, kinda following 6750, when
dpop_proof is sent it's in a query for GET, in the request body for a POST.
my provider for instance will ignore query parameters during a POST. With
that said, what about RS endpoints using other methods? Maybe placing the
proof in a header isn't a terrible idea afterall.
Kind Regards,
*Filip Skokan*
On Thu, 28 Mar 2019 at 11:19, Daniel Fett <danielf+oa...@yes.com>
<mailto:danielf+oa...@yes.com>>; 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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
* [OAUTH-WG] draft-fett-oauth-dpop-00
<https://mailarchive.ietf.org/arch/msg/oauth/9jETD0i94pq6ZM290c9PnxUUAkw>
Daniel Fett
* Re: [OAUTH-WG] draft-fett-oauth-dpop-00
<https://mailarchive.ietf.org/arch/msg/oauth/IHt83R7tGwb9iuC9MhPTFIDJrAI> Mike
Jones
* Re: [OAUTH-WG] draft-fett-oauth-dpop-00
<https://mailarchive.ietf.org/arch/msg/oauth/0uBLlJe9eA8TONn7ykaPDSj2bVQ>
Ludwig Seitz
* Re: [OAUTH-WG] draft-fett-oauth-dpop-00
<https://mailarchive.ietf.org/arch/msg/oauth/d9i047xb8SgFk1VeIP36DEdRA5Y>
Filip Skokan
* Re: [OAUTH-WG] draft-fett-oauth-dpop-00
<https://mailarchive.ietf.org/arch/msg/oauth/ZwOJqiQFTs42XUrNF4ZMQWfayhQ>
Filip Skokan
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
