Hello Nicolas,
The situation you describe of nonce switching with different RSs using the
same domain is possible. But I believe in practice it's rather unlikely to
occur and is self correcting even if it does occur (though kinda
chatty/inefficient). I don't believe it's worthwhile to add stuff to
On Wed, Mar 23, 2022 at 5:01 PM Rohan Mahy wrote:
> Hi Brian,
>
> To be clear, for pre-generated proofs, I am not worried about an attack
> against the client; I am worried about a malicious client. Imagine a
> malicious client which pre-generates proofs during a brief window while it
> has acces
Thanks George, I agree that there are “on behalf-off” authorization use cases
where strict proximity enforcement could be problematic.
I think of proximity as one of the controls that can be applied and influence
the risk assessment. For example, the authorization server may still issue
authori
Hi Brock, one of the options to consider here is just better guidance in terms
of implementation, including guidance on selecting protocols. From looking at
numerous exploits (not just the authroization grant flow and the social
engineering exploits), implementation issues is by far the most pre
Yep +1
But also... in my experience, FWIW, the dev generally wants to do the right
thing and follow the guidance, but then you get the product
owner/marketing/sales/UX/designer people who then want to make things as
friction-less for the end user/customer (which often translates into revenue).
Given the suggested protocol for step up (I just watched the talk in
Vienna, thanks Vittorio & Brian) - how could an RS signal that it simply
wants the end-user re-authenticated, without being concerned about the ACR?
Vladimir
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographi
I believe through the use of max_age.
- Filip
> 24. 3. 2022 v 15:59, Vladimir Dzhuvinov :
>
> Given the suggested protocol for step up (I just watched the talk in Vienna,
> thanks Vittorio & Brian) - how could an RS signal that it simply wants the
> end-user re-authenticated, without being co
Hi Brian,
1) Re: requiring a nonce or an expiration time, I'll propose some specific
text.
Section 4.2
insert after "* iat: Time at which the JWT was created (REQUIRED)."
"The DPoP proof MUST include either one or both of the following:
* exp: time after which the proof is no longer valid.
* non
