All,
Take a look at the following links for the April 12th interim meeting
minutes:
https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-05-oauth
https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-05-202104121200/
Thanks to *Dick Hardt *for taking these notes.
Regards,
Rifaat &
Sorry I ment "ath" was fine as a claim name for that. I added the extra u.
On 4/12/2021 11:28 AM, Justin Richer wrote:
> As mentioned, my own intention for using a new claim “ath” was to have
> a fixed hash size, not dependent on the surrounding JWS envelopes that
> “at_hash” is based on. I’ve
As mentioned, my own intention for using a new claim “ath” was to have a fixed
hash size, not dependent on the surrounding JWS envelopes that “at_hash” is
based on. I’ve implemented both approaches on several platforms now, and I
greatly prefer the fixed hash.
It’s a new name because it is a
Am 12.04.21 um 16:56 schrieb Denis:
> Hi Daniel,
>
>> (...)
As I'm sure you have noticed, we have updated Section 3 following
your last input. It now explicitly says:
Attackers can collaborate to reach a common goal.
It also says
Note that in
Hi Steinar,
Please read first the response just posted to Daniel.
Hi Denis, I don't understand the attack or the countermeasures you are
describing completely - but that doesn't really matter.
Since it does not matter, let us continue. :-)
As far as I know OAuth doesn't require a specific
Hi Daniel,
(...)
As I'm sure you have noticed, we have updated Section 3 following
your last input. It now explicitly says:
Attackers can collaborate to reach a common goal.
It also says
Note that in this attacker model, an attacker (see A1) can be a RO or
act as one. For
Hi Denis,
Am 12.04.21 um 14:57 schrieb Denis:
>>
>>> The first sentence of section 3 (The Updated OAuth 2.0 Attacker
>>> Model) clearly states:
>>>
>>> " In the following, this attacker model is updated (...) to
>>> include new types of attackers and to define the attacker model more
>>>
Hi Denis, I don't understand the attack or the countermeasures you are
describing completely - but that doesn't really matter.
As far as I know OAuth doesn't require a specific token format, so the
countermeasure you describe is based on an assumption that the AT is a JWT.
If that's the case,
Hi Daniel,
Denis,
I was awaiting your mail and I admire your perseverence with bringing
this topic to our attention.
[Denis] I admire your perseverence with constantly refusing to include
this attack. :-)
To your points:
Am 12.04.21 um 13:36 schrieb Denis:
The case where two clients
Denis,
I was awaiting your mail and I admire your perseverence with bringing
this topic to our attention.
To your points:
Am 12.04.21 um 13:36 schrieb Denis:
> The case where two clients collude to mount an attack against a RS is
> not addressed. It now needs to be addressed.
>
>
> This should
To all,
In RFC 6819 OAuth 2.0 Security), it is assumed in section 2.2 (Attack
Assumptions)that :
* two of the three parties involved in the OAuth protocol may collude
to mount an attack against the 3rd party.
For example, the client and authorization server may be under
control of
11 matches
Mail list logo
