Thanks Rifaat,
I've just pushed out a -08 draft with changes addressing feedback received
during WGLC.
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
On Mon, Mar 28, 2022 at 6:01 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> As discussed during the IETF meeting in *Vienna* last week,
Thanks Nat,
on 5: Server authentication was kind of assumed throughout the draft due to
HTTPS being required but I think you're right that it might be good to add
something more explicit about it. I'll add something towards that end in
the next revision.
on 3/4: I kind of liked the one line "cnf"
I support publication.
John Bradley
-- Original Message --
From: "Nat Sakimura"
To: "Rifaat Shekh-Yusef" ; "oauth"
Sent: 4/7/2022 10:37:21 PM
Subject: Re: [OAUTH-WG] WGLC for DPoP Document
Thanks for an excellent work.
I am happy that the public key
Thanks for an excellent work.
I am happy that the public key confirmation method in JPOP [1] presented at
IETF OAuth WG in 2017 somewhat morphed into DPOP after 5 years. Also, I was
very happy to see the
[1] https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-jpop-00
I also apologize that
I support DPoP publication
--
Vladimir Dzhuvinov
On 28/03/2022 15:01, Rifaat Shekh-Yusef wrote:
All,
As discussed during the IETF meeting in *Vienna* last week, this is a
*WG Last Call *for the *DPoP* document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Please, provide your
I support publication
From: OAuth On Behalf Of Warren Parad
Sent: Wednesday 30 March 2022 13:12
To: Torsten Lodderstedt
Cc: oauth
Subject: Re: [OAUTH-WG] WGLC for DPoP Document
I support publication.
[https://lh6.googleusercontent.com
Mar 29, 2022, at 3:12 PM, Mike Jones <
>>> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>>>
>>> I support publication of the specification.
>>>
>>> -- Mike
>>>
>>> *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef
&
-- Mike
>>>
>>> From: OAuth mailto:oauth-boun...@ietf.org>> On
>>> Behalf Of Rifaat Shekh-Yusef
>>> Sent: Monday, March 28, 2022 5:01 AM
>>> To: oauth mailto:oauth@ietf.org>>
>>> Subject: [OAUTH-WG] WGLC for DP
cation.
>>
>>-- 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,
>
, 2022, at 3:12 PM, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
> I support publication of the specification.
>
>-- Mike
>
> *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* Monday, March
:*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*last week, this is
a*WG Last Call*for the *DPoP*document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Please, provide your feedback on the mailing
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
ef
> 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 last week, this is a WG Last
> Call for the DPoP document:
> https://datatracker.ietf.org/doc/draft-ietf-oau
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
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
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
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
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
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
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
+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
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
> On Mar 28, 2022, at 8:28 AM, Denis wrote:
>The primary aim of DPoP is to bind a token to a public key upon
> issuance and requiring that the client proves possession
>of the corresponding private key when using the token. This does not
> demonstrate that the client
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 token, the illegitimate client can do anything it wants with it.
The legitimate client can be kept
Interesting, but won't two collaborating clients just pass any data they
want to each other? Why would these collaborating clients go through the
trouble of exchanging private keys, dpop proofs or tokens? Could you
elaborate some more on the scenario?
S
man. 28. mar. 2022 kl. 16:29 skrev Denis :
Rifaat & Hannes,
Hereafter are my comments:
The introduction states :
Recipients of such tokens are then able to verify the binding of
the token to the key pair thatthe client has demonstrated
that it holds via the DPoP header, thereby providing some
assurance that the client
All,
As discussed during the IETF meeting in *Vienna* last week, this is a *WG
Last Call *for the *DPoP* document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Please, provide your feedback on the mailing list by April 11th.
Regards,
Rifaat & Hannes
31 matches
Mail list logo
