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

While there are certainly more than a few different ways of approaching it, I am still not convinced of any significant advantage to tracking iat + a slightly smaller jti value vs. what is currently in the draft. And as we are trying to reflect WG consensus here rather than one person's opinion, I

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

Hi Brian, The client is not necessarily identified in requests to the RS (it could be via the access token but that's an implementation detail that can't be counted on in spec) so maintaining a per client list isn't viable. That as well as some other considerations/approaches were talked abo

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

The client is not necessarily identified in requests to the RS (it could be via the access token but that's an implementation detail that can't be counted on in spec) so maintaining a per client list isn't viable. That as well as some other considerations/approaches were talked about in https://gi

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

I think perhaps an assumption in the DPoP draft (and in the description of “jti” in RFC 7519) is that the server will maintain a single global list of recently used jti values to prevent replay, rather than maintaining a separate list per client. That could perhaps be spelled out more clearly in

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

The conversation at https://github.com/danielfett/draft-dpop/pull/51#discussion_r332377311 has a bit more of the rational behind the choice of 96 bit minimum. On Wed, Dec 2, 2020 at 7:07 AM Denis wrote: > Hi Daniel, > > All your arguments make sense. I agree. > > A minor point however. The size

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

Hi Daniel, All your arguments make sense. I agree. A minor point however. The size of the jti" is currently mandated to 96 bits minimum. This is unnecessarily long for a time window of a few minutes. The jti" does not need to be a unique identifier valid for ever. It can simply be an identifie

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

Thanks Dick. On Tue, Dec 1, 2020 at 1:43 PM Dick Hardt wrote: > I have 2 suggestions for the draft that I beleive address the issues Denis > is bringing up: > > 1) call out that a DPoP proof can only be used once, and a new DPoP proof > is needed for every API call. Apologies if that is in the t

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

I have 2 suggestions for the draft that I beleive address the issues Denis is bringing up: 1) call out that a DPoP proof can only be used once, and a new DPoP proof is needed for every API call. Apologies if that is in the text -- but I could not find it doing a skim over the document. 2) Provide

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

So what you are proposing is that the time window in which an RS accepts the DPoP proof is defined by the expiration time of the access token? DPoP proofs are intended to be generally be short-lived and fresh for each request in order to provide some level of replay protection. There is no point i

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

Hi  Brian, 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

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

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 r

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

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 preferabl

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

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/int