The spec is fine, we've had it implemented for some time now and support
its publication.
+1 to Brian's comment. I suppose it suffices to say the iss parameter is
redundant when JARM is used as JARM provides the same countermeasure. I
found the normative text about what JARM allows or
Thanks Karsten,
That's moving in the right direction. But I think the last sentence is
still too strong and maybe prone to misunderstanding given it's not 100%
obvious in the JARM case what exactly constitutes an authorization response
parameter.
I'd say the last sentence could just be dropped
Hi Karsten,
I've read the specification and implemented it. I think that the
specification is good enough for implementers. Actually, the latest version
of my company's product supports the specification and has already been
rolled out. The release note of the version mentions the specification.
Hi Brian,
thank you for your feedback.
I agree that the language is too strong here. What do you think about
this new note?
Note: The "JWT Secured Authorization Response Mode for OAuth 2.0
(JARM)" [JARM] defines a mechanism that conveys all authorization
response parameters in a JWT. This
Overall it looks pretty good to me.
One little nit is that I don't love this text from the end of sec 2.4 that
talks about JARM:
'Note: The "JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)"
[JARM] forbids the use of additional parameters in the authorization
response. Therefore, the
Perhaps this draft could be marked as replacing
draft-ietf-oauth-mix-up-mitigation (I think the chairs have the tools to do
that) so that the datatracker somewhat reflects the history?
Some discussion in the draft itself might be helpful to a subset of readers
interested or knowledgeable about
Hi Neil,
I'm not sure - maybe others can chime in here as well - if a discussion
relating to an expired previous draft is something one would expect in
the spec.
For the record, the client_id does not provide any additional security.
The key to mitigating Mix-Up is that the "honest AS" ensures
I have also read it and it looks good to me. It might be worth explicitly
discussing how it relates to the older draft [1] (that we implemented at the
time). That older draft also included a client_id parameter in the response, so
it would be good to clarify if that is actually needed to
Hi all,
I reviewed the document and have no objections. I think we can move
forward with the next steps.
Best regards
Vladislav Mladenov
Am 09.05.21 um 12:11 schrieb Torsten Lodderstedt:
> Hi,
>
> I have read the document and have no concerns.
>
> As an editorial feedback, I would suggest to
Hi,
I read the document, have no concerns, and support it.
Christian
On 01.05.21 22:46, Rifaat Shekh-Yusef wrote:
All,
We have not seen any comments on this document.
Can you please review the document and provide feedback, or indicate that
you have reviewed the document and have no
Hi,
I have read the document and have no concerns.
As an editorial feedback, I would suggest to drop „ If implemented correctly,“
in the abstract since this apparently is a prerequisite for all kinds of
security controls ;-)
best regards,
Torsten.
> Am 01.05.2021 um 22:47 schrieb Rifaat
All,
We have not seen any comments on this document.
Can you please review the document and provide feedback, or indicate that
you have reviewed the document and have no concerns.
Regards,
Rifaat & Hannes
On Thu, Apr 15, 2021 at 3:04 AM Karsten Meyer zu Selhausen <
12 matches
Mail list logo
