[Openid-specs-ab] Issue #1164: insecure front-channel use of private_key_jwt client authentication (openid/connect)
stuart at biza.io
Tue Apr 21 09:38:37 UTC 2020
>> On 21 Apr 2020, at 07:56, Roland Hedberg via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
>> If we use signed request objects, do we mandate it for all authorization requests or just for the first one.
>> If one uses explicit dynamic registration you do the registration and then you do authorization requests
>> using any of the available methods until the registration runs out.
>> Using the same ‘model’ for automatic client registration you would only have to use a signed request object
>> when you needed to ‘register’.
> From the clients point of view, would most people choose not to track the state and hence always use signed requests if they’re doing automatic registration? (Not to mention that I’m sure registrations are at some point likely to get lost without running out?)
> If you’ve already got them implemented and working, is there ever a downside to sending signed requests?
> (That doesn’t directly answer the question of whether the server should mandate it though - if the security architecture is generally happy with unsigned requests I can’t see a reason to strongly mandate it at the server side.)
It would seem my reception on openid-specs-ab is patchy but I’m reminded of my original comments during the Federation draft review:
Not sure why Mailman/Pipermail has seen fit to censor me but nonetheless I did flag the “how to verify parties”.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab