Re: [OAUTH-WG] DPoP Interim Minutes

[Dick Hardt]

Thanks to those addressing the points I missed during the meeting!
ᐧ

On Mon, Nov 30, 2020 at 3:15 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> You can find the minutes of the *DPoP* meeting here:
>
> https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/minutes-interim-2020-oauth-16-202011301200-01
> and here:
> https://codimd.ietf.org/notes-ietf-interim-2020-oauth-16-oauth?view
>
> Thanks to *Dick Hardt* for taking these notes.
>
> Regards,
>  Rifaat & Hannes
> ___
> 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

[OAUTH-WG] DPoP Interim Minutes

[Rifaat Shekh-Yusef]

All,

You can find the minutes of the *DPoP* meeting here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/minutes-interim-2020-oauth-16-202011301200-01
and here:
https://codimd.ietf.org/notes-ietf-interim-2020-oauth-16-oauth?view

Thanks to *Dick Hardt* for taking these notes.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Brian Campbell]

Hi Denis,

The choice to use "iat" vs. "exp" was made in the summer of last year. You
can see some of the discussion from then in
https://github.com/danielfett/draft-dpop/issues/38. I believe it pretty
well has consensus at this point and thus unlikely to be changed.

While I do believe there are reasonable arguments that can be made on both
sides of using either of "iat" or "exp", it's difficult (and honestly time
consuming and very frustrating) to try and have such discussions or even
respond in a coherent way when fundamental aspects of the draft are
misrepresented or misunderstood. For example, the DPoP proof JWT is created
by the client not the AS so the advantages you put forward are nonsensical
in the context of the actual workings of the draft.





On Mon, Nov 30, 2020 at 8:45 AM Denis  wrote:

> One comment on slide 5 about the *time window*.
>
> At the bottom, on the left, it is written: "Only valid for a limited *time
> window* relative to creation time".
>
> While the creation time is defined by "iat", the *time window* is
> currently left at the discretion of each RS.
>
> It would be preferable to mandate the inclusion in the JWT of the exp
> (Expiration Time) Claim.
> In this way, the *time window *would be defined by the AS using both the
> "iat" and the "exp" claims.
>
> This would have the following advantages:
>
>- The client will know whether a token is still usable and is unlikely
>to get a rejection of the token
>because of an unknown time window defined by a RS.
>
>
>- The RS is able to manage better the "jti" claim values, because it
>will be able to discard "jti" claim values
>as soon as they are outside the time window defined by the AS in a JWT.
>
> Denis
>
> All,
>
> This is a reminder that we have an Interim meeting this Monday, Nov 30th @
> 12:00pm ET, to discuss the latest with the *DPoP *document:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>
> You can find the details of the meeting and the slides here:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP Binding JWT proposal

[Dick Hardt]

Pushing this to the top of the stack in case there is interest in
separating the binding mechanism from the RT / AT so that existing RTs /
ATs can be used.
ᐧ

On Fri, Nov 6, 2020 at 2:12 PM Dick Hardt  wrote:

> Hello
>
> After reviewing the DPoP spec, and reflecting on implementations I have
> worked with, I wanted to see if there was interest in a DPoP Binding JWT.
>
> The use case is to enable existing deployments to add support for DPoP
> without having to replace their existing refresh token and access tokens,
> and the processing of them as the DPoP Binding JWT processing can be added
> as an independent software layer.
>
> The processing overhead is minimized as the DPoP Binding JWT
> verification can be cached for an access token,
> adding only one JWT verification for the lifetime of the access token.
>
> DPoP Binding JWTs using asymmetric cryptographic algorithms, provide the
> increased security of public / private key for existing deployments using
> access tokens signed with shared secrets such as HMAC.
>
> /Dick
>
>
> *X. DPoP Binding JWT*
> Deployments that do not want to modify their existing access tokens or
> resource tokens to contain
> the DPoP thumbprint can include DPoP Binding JWTs in the response from
> the AS and present them in
> calls to the RS. A DPoP Binding JWT contains the DPoP thumbprint and a
> hash of the access token
> or refresh token, and is signed by the AS.
>
> The use of DPoP Binding JWTs enables existing deployments to add
> proof-of-possession assurance to
> existing deployments by adding a middle layer service or software
> without modifying the processing
> of refresh tokens or access tokens.
>
>
>
> *X.1 DPoP Binding JWT Syntax*
> * "typ": type header, value "dpop-binding+jwt"
>
> * "jti": unique id
> * "iat": time created
> * "jkt": JWK SHA-256 Thumbprint of the DPoP public key
>
> If binding an access token
> * "ath": SHA-256 hash of the access token
>
> If binding an refresh token
> * "rth": SHA-256 hash of the refresh token
>
> Example DPoP Binding JWT for an access token:
>
> {
> "typ":"dpop-binding+jwt",
> "alg":"ES256",
> "jwk": {
> "kty":"EC",
> "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
> "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
> "crv":"P-256"
> }
> }.{
> "jti":"-BwC3ESc6acc2lTc",
> "iat":1562262616,
> "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I",
> "ath":"N0d2HglBV3uiguA4I0ZcOCORZNYy-DWpqq30jZyJGHT"
> }
>
>
>
> *X.2 Checking DPoP Bindings*
> Check the DPoP Binding JWT is valid
> Check the DPoP Binding JWT "jkt" value matches the thumbprint of the
> DPoP public key
> Check the DPoP Binding JWT "ath" value matches the SHA-256 hash of the
> access token
>   or
> Check the DPoP Binding JWT "rth" value matches the SHA-256 hash of the
> refresh token
>
>
> *X.3 Token Response*
> The AS sets the "token_type" parameter to "DPoP-Binding".
> The AS returns the DPoP Binding JWT for the access token in the
> "access_token_binding" parameter,
> and the DPoP Binding JWT for the refresh token in the
> "refresh_token_binding" parameter.
>
>  HTTP/1.1 200 OK
>  Content-Type: application/json;charset=UTF-8
>  Cache-Control: no-store
>  Pragma: no-cache
>
>  {
>"access_token":"2YotnFZFEjr1zCsicMWpAA",
>"access_token_binding":"eyJ0eXAiOiJkcG9w",
>"token_type":"DPoP-Binding",
>"expires_in":3600,
>"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
>"refresh_token_binding":"eyJ0eXAiOiJkcG9w."
>"example_parameter":"example_value"
>  }
>
>
> *X.4 Resource access*
> The client presents the access token DPoP Binding JWT in the
> "DPoP-Binding" HTTP header.
>
> GET /protectedresource HTTP/1.1
> Host: resource.example.org
> Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6IkJlQUxrYiJ9.eyJzdWI
> iOiJzb21lb25lQGV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbX
> BsZS5jb20iLCJhdWQiOiJodHRwczovL3Jlc291cmNlLmV4YW1wbGUub3JnIiwibmJmI
> joxNTYyMjYyNjExLCJleHAiOjE1NjIyNjYyMTYsImNuZiI6eyJqa3QiOiIwWmNPQ09S
> Wk5ZeS1EV3BxcTMwalp5SkdIVE4wZDJIZ2xCVjN1aWd1QTRJIn19.vsFiVqHCyIkBYu
> 50c69bmPJsj8qYlsXfuC6nZcLl8YYRNOhqMuRXu6oSZHe2dGZY0ODNaGg1cg-kVigzY
> hF1MQ
> DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik
> VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
> nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE
> QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj
> oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z
> WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E74kWCiGB
> NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-uyUI4AUg1JSskfWIyo4UCbQ
> DPoP-Binding: eyJ_an_example_DPoP_bi

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Denis]

One comment on slide 5 about the /time window/.

At the bottom, on the left, it is written: "Only valid for a limited 
/time window/ relative to creation time".


While the creation time is defined by "iat", the /time window/ is 
currently left at the discretion of each RS.


It would be preferable to mandate the inclusion in the JWT of the exp 
(Expiration Time) Claim.
In this way, the /time window /would be defined by the AS using both the 
"iat" and the "exp" claims.


This would have the following advantages:

 * The client will know whether a token is still usable and is unlikely
   to get a rejection of the token
   because of an unknown time window defined by a RS.

 * The RS is able to manage better the "jti" claim values, because it
   will be able to discard "jti" claim values
   as soon as they are outside the time window defined by the AS in a JWT.

Denis



All,

This is a reminder that we have an Interim meeting this Monday, Nov 
30th @ 12:00pm ET, to discuss the latest with the *DPoP *document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ 



You can find the details of the meeting and the slides here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth 



Regards,
 Rifaat & Hannes


___
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