Re: [OAUTH-WG] PAR error for redirect URI?

If people have articulated a need to have an invalid_redirect_uri error for the PAR endpoint, then let's register it properly. Rifaat says there's still time to do this. I'm also okay with using the general invalid_request code for this. In this case a sentence, next to the current example, spelli

Re: [OAUTH-WG] DPoP followup II: confirmation style

Hi Brian, everyone The option 2 makes sense to me, because I think the DPoP Proof to AS and the one to RS play different roles. Maybe they should even have different names. However, AS/RS symmetry of option 1 is also attractive from the viewpoint of an implementer. I think this topic is related t

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

I understand. Thanks! I think RT rotation + RT hash in the proof would also stop the attack. > Am 03.12.2020 um 13:19 schrieb Filip Skokan : > > I'm failing to understand why binding the proof to the access token ensures > freshness of the proof. > > Because when access tokens issued to pub

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

> > I'm failing to understand why binding the proof to the access token > ensures freshness of the proof. Because when access tokens issued to public browser based clients have a short duration you need continued access to the private key to issue new proofs. When I exfiltrate the RT and pre-gene

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] DPoP followup I: freshness and coverage of signature

Hi, I'm failing to understand why binding the proof to the access token ensures freshness of the proof. I would rather think if the client is forced to create proofs with a reasonable short lifetime, chances for replay could be reduced. Beside that as far as I remember the primary replay coun

[OAUTH-WG] PAR error for redirect URI?

Torsten, Filip, You can absolutely make this change, as we are still very early in the process. So feel free to continue this effort and try to get WG agreement on this, and update the document as needed. Regards, Rifaat On Thursday, December 3, 2020, Filip Skokan wrote: > To be clear, I'm n

Re: [OAUTH-WG] DPoP followup III: client auth

I like the last option :-) > On 2 Dec 2020, at 22:29, Brian Campbell > wrote: > > There were a few items discussed somewhat during the recent interim > > that I committed to bringing back to the list. The slide below (

Re: [OAUTH-WG] DPoP followup II: confirmation style

Strongly in favour of 2. I think history shows that successful standards make security checks hard to get wrong rather than merely easy to get right. — Neil > On 2 Dec 2020, at 22:28, Brian Campbell > wrote: > > There were a few items discussed somewhat during the recent interim >

Re: [OAUTH-WG] PAR error for redirect URI?

To be clear, I'm not advocating to skip the registration, just wanted to mention a potential concern. If the process allows it and it will not introduce more delay to publication, I think we should go ahead and register the error code. Best, *Filip* On Thu, 3 Dec 2020 at 11:06, Torsten Lodderste

Re: [OAUTH-WG] OAuth 2.1 + OAuth 2.0 for Native Apps: Private-Use URI Scheme Redirection enforcement

Please note that this simple validation (in combination with web application enforcing http(s) schemes) removes the need to implement and maintain a blocklist of potentially malicious schemes such as `javascript:/`, `vbscript:/`, and `data:/`. More details: https://security.lauritz-holtmann.de/pos

Re: [OAUTH-WG] PAR error for redirect URI?

> Am 03.12.2020 um 09:56 schrieb Filip Skokan : > > There are several documents already mentioning "invalid_redirect_uri" as an > error code, specifically RFC7519 and OpenID Connect Dynamic Client > Registration 1.0. But these don't register it in the IANA OAuth Extensions > Error Registry, p

[OAUTH-WG] OAuth 2.1 + OAuth 2.0 for Native Apps: Private-Use URI Scheme Redirection enforcement

Hello everyone, Both RFC 8252 and OAuth 2.1 draft state that (paraphrasing) Apps MUST use a URI scheme based on a domain name under their control, > expressed in reverse order,

Re: [OAUTH-WG] PAR error for redirect URI?

There are several documents already mentioning "invalid_redirect_uri" as an error code, specifically RFC7519 and OpenID Connect Dynamic Client Registration 1.0. But these don't register it in the IANA OAuth Extensions Error Registry, presumably because they're neither for the authorization or token