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

On Thu, Dec 3, 2020 at 5:55 PM wrote: > I think this topic is related to the question of "followup I: freshness and > > coverage of signature". The option 2 for the followup I will also break > AS/RS > > symmetry. If we choose the option 2 for followup I, I think we might as > well > > choose

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

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

On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov wrote: > 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. > Following from the response I recently sent to Neil, I

[OAUTH-WG] Reminder - Interim Meeting on Dec 7th

All, This is a reminder that we have an interim meeting this coming Monday to discuss the following document: https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ The following link has the details of the meeting and slides:

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

That's a good point. The context of the original discussion that led to this thread wasn't about a client programmatically acting on the information. Rather that banks (and similar entities) can be reluctant to include additional info in descriptive error messages so having a specific error code

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

> The suggestion to use a web worker to ensure that proofs cannot be > pre-computed is a good one I think. (You could also use a sandboxed iframe > for a separate sub/sibling-domain - dpop.example.com > ). An iframe with a different origin would also work (not really

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

Thanks Philippe, this is a good analysis. The suggestion to use a web worker to ensure that proofs cannot be pre-computed is a good one I think. (You could also use a sandboxed iframe for a separate sub/sibling-domain - dpop.example.com ). For scenario 4, I think this

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

Hi all, This is a very useful discussion, and there are some merits to using DPoP in this way. However, the attacker's capabilities are stronger than often assumed, so it may not matter in the end. I've been wanting to write this out for a while now, so I've added a couple of scenarios below.

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

Making it a specific error code rather than just an error message suggests that the client can do something with that information. That doesn’t seem likely to me. It’s most likely caused by a misconfiguration that somebody needs to manually sort out rather than something that can be