Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[rich levinson <[e-mail]>]

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 <[e-mail]>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 <[e-mail]>  <mailto:[e-mail]&gt>; 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 <[e-mail]>  <mailto:[e-mail]&gt>; 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
>> [e-mail]  <mailto:[e-mail]>
>> 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