I read all the comments carefully while flying through Brazil, and I
confess that my reasoning from the beginning tended to say that the OAuth
trust model is “as is” and that the main point of the trust relationship is
between the AS and the RO (in this case, a user).
At various times, while readi
I think the problem here for me is that lack of clarity of how this problem
could be better constrained at the protocol level. As far as I can see,
albeit naively, the problem is purely an internal implementation detail. Is
that not the case? Is there really something missing in the grants that
wou
It could be an internal implementation like any part of OAuth could be, but
from the OAuth perspective, the intent was to create a new Grant Type, that
is not mandatory, but part of the framework. So, this Grant Type
standardizes the generic flow to the AS to obtain the authorization
evidence token
Let me try that differently, I posit that it might be impossible to secure
this in a way that would prevent a different Relying Party from
impersonating the user if we only use details *about* the user. However, we
do know that using FIDO2 the user can secure communication with the AS, in
a way tha
Great, Warren!! I believe that FIDO2 may be recommended on the BCP. But,
first we need an agnostic/generic grant-type to this flow.
Em ter., 15 de ago. de 2023 às 15:35, Warren Parad escreveu:
> Let me try that differently, I posit that it might be impossible to secure
> this in a way that woul
