I support publication of the specification
On Wed, 30 Mar 2022 at 08:55, Daniel Fett wrote:
> I also support publication.
>
> -Daniel
> Am 29.03.22 um 23:20 schrieb David Waite:
>
> I also support publication of this specification
>
> -DW
>
> On Mar 29, 2022, at 3:12 PM, Mike Jones <
> Michael.J
I also support publication.
-Daniel
Am 29.03.22 um 23:20 schrieb David Waite:
I also support publication of this specification
-DW
On Mar 29, 2022, at 3:12 PM, Mike Jones
wrote:
I support publication of the specification.
-- Mike
*From:*OAuth *On Behalf Of*Rifaat Shekh-Yusef
*Sent:*Monday
I would like to un-ask my question. Is there a «retract mail» option
somewhere?
PS! This is written by my wife, with whom I have colluded many times. She
even knows the PIN code on my bank cards.
tir. 29. mar. 2022 kl. 22:08 skrev Hans Zandbelt :
>
>
> On Tue, Mar 29, 2022 at 9:54 PM Denis wr
I also support publication of this specification
-DW
> On Mar 29, 2022, at 3:12 PM, Mike Jones
> wrote:
>
> I support publication of the specification.
>
>-- Mike
>
> From: OAuth On Behalf Of Rifaat Shekh-Yusef
> Sent: Monday, March
Hi Hans,
Hi Denis,
thanks for correcting the thread topic:
On Tue, Mar 29, 2022 at 10:19 PM Denis wrote:
nothing stops Alice from logging in on Bob's device, obtaining
tokens for access and then leave Bob with the device, even in
long term user accounts
Even so, Alice will
I support publication of the specification.
-- Mike
From: OAuth On Behalf Of Rifaat Shekh-Yusef
Sent: Monday, March 28, 2022 5:01 AM
To: oauth
Subject: [OAUTH-WG] WGLC for DPoP Document
All,
As discussed during the IETF meeting in Vienna
Hi Denis,
thanks for correcting the thread topic:
On Tue, Mar 29, 2022 at 10:19 PM Denis wrote:
> nothing stops Alice from logging in on Bob's device, obtaining tokens for
> access and then leave Bob with the device, even in long term user accounts
>
> Even so, Alice will be unable to use that
Hans,
Please do not mix topics. I have changed the title of that thread, for
not polluting the original one.
On Tue, Mar 29, 2022 at 9:54 PM Denis wrote:
Nothing stops Alice from giving her token that says “This is
Alice” to Bob and having Bob use it.
Such scenario does not e
On Tue, Mar 29, 2022 at 9:54 PM Denis wrote:
> Nothing stops Alice from giving her token that says “This is Alice” to Bob
> and having Bob use it.
>
> Such scenario does not exist in the context of long term user accounts.
> However, it is important first to understand the concept
> of long term
Justin,
Denis,
This is why the use of “iat” and “nonce” are recommended, to prevent
this kind of replay, and these are already discussed in the draft.
Having a highly targeted request with narrow presentation window is
desirable in most cases, but some applications of DPoP do want to have
a
Denis,
This is why the use of “iat” and “nonce” are recommended, to prevent this kind
of replay, and these are already discussed in the draft. Having a highly
targeted request with narrow presentation window is desirable in most cases,
but some applications of DPoP do want to have a pre-generat
Hi Justin,
In this scenario, the “legitimate” client _never_ gives away its secrets
(if it is using a secure platform, it can't). It never give away its
credentials either.
When using key bound access tokens, a RS can't know whether the access
token is presented by the “legitimate” client
I agree that the at_hash definition is bizarre. I suggest adding a sentence
when introducing the ath claim explaining that this is similar but
different from at_hash.
Thanks,
-rohan
On Tue, Mar 29, 2022 at 6:14 AM Justin Richer wrote:
> Yes, it was considered, discussed, and rejected. The reaso
If the “legitimate” client willingly gives away its secrets and tokens to the
“illegitimate” client, then the latter isn’t actually “illegitimate” anymore.
What I was saying is that the “attack" is not even necessary if the clients are
in fact working together. If the “legitimate” client knowing
Hi all,
We have encountered a situation in the wild which I would like to share and
discuss with you.
We have strict validation of the iat claim as per section 4.3 in the
specification where we allow a reasonable skew.
The problem we see is that some users (more than a few) have changed the
cloc
Dear all,
thanks for this interesting work! I think that there's some editorial work
that should be done
on terminology (e.g. a consistent use of JOSE header parameter, HTTP header
field, ...)
and some simplification will really make the spec more easy to read.
For example, once defined that the
Hi Justin,
You broke the thread since you have not re-used the last message which was:
Steinar,
As you have guessed, no data (except the token and some crypto
checksums) is passing through the clients.
Once the legitimate client has allowed the illegitimate client to
use the to
Yes, it was considered, discussed, and rejected. The reason being “at_hash” has
a somewhat convoluted definition (left-bits of a hash of an access token in the
context of a JOSE object, etc), to fit some of the design constraints of ID
Tokens. DPoP proofs do not have those same constraints. DPoP
+1
Am 29.03.22 um 15:10 schrieb Justin Richer:
And this is exactly the problem with the “collaborating clients”
attack, as has been pointed out any number of times it’s been brought
up before. If two clients are willingly collaborating in this way,
they do not need to share any cryptographic m
And this is exactly the problem with the “collaborating clients” attack, as has
been pointed out any number of times it’s been brought up before. If two
clients are willingly collaborating in this way, they do not need to share any
cryptographic material and impersonate each other.
You don’t ne
20 matches
Mail list logo
