The tl;dr is that I believe Neil's suggestion is of sufficient merit to
warrant seriously considering making the change.
That was more words than it needed to be too. But maybe clarifies.
On Tue, Sep 15, 2020 at 4:51 PM Dick Hardt wrote:
> That was a lot of words Brian. What is the "tl;dr:"?
That was a lot of words Brian. What is the "tl;dr:"? (I read it, but I'm
not sure where you landed given your last sentence)
ᐧ
On Tue, Sep 15, 2020 at 3:16 PM Brian Campbell wrote:
> Sorry for the slow reply to this one, Neil. It's gotten me thinking a bit
> and it took some time to gather my
Sorry for the slow reply to this one, Neil. It's gotten me thinking a bit
and it took some time to gather my thoughts and attempt to articulate them.
It is true that, as defined in the current -01 draft, there is the
additional step for the RS to check that the proof key matches the hash in
the
rom: Brian Campbell
Sent: Wednesday, September 9, 2020 7:45 AM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ)
Cc: oauth
Subject: Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?
Indeed there are cases, as you point out, where the key might be knowable to
the server via
e the same key. That would be bad.
From: Takahiko Kawasaki
Sent: Tuesday, September 8, 2020 11:23 PM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ)
Cc: oauth
Subject: Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?
To enable each "instance" of a cl
+1 for keeping it simple. The design itself promotes unique-per-instance
keys, not pre-registration.
S pozdravem,
*Filip Skokan*
On Wed, 9 Sep 2020 at 00:46, Brian Campbell wrote:
> Indeed there are cases, as you point out, where the key might be knowable
> to the server via some other means,
I disagree with this rationale, I’m afraid. I don’t think the simplicity gain
for the client is really very great and I think we will regret this decision.
Most importantly, including the JWK directly in the proof token increases the
likelihood that somebody will just validate the signature
+1
KISS
ᐧ
On Tue, Sep 8, 2020 at 3:55 PM John Bradley wrote:
> +1
> On 9/8/2020 7:45 PM, Brian Campbell wrote:
>
> Indeed there are cases, as you point out, where the key might be knowable
> to the server via some other means, which makes the "jwk" header in the
> DPoP proof not strictly
+1
On 9/8/2020 7:45 PM, Brian Campbell wrote:
> Indeed there are cases, as you point out, where the key might be
> knowable to the server via some other means, which makes the "jwk"
> header in the DPoP proof not strictly necessary. And while omitting
> the key in such cases would reduce the size
Indeed there are cases, as you point out, where the key might be knowable
to the server via some other means, which makes the "jwk" header in the
DPoP proof not strictly necessary. And while omitting the key in such cases
would reduce the size of some messages (the DPoP proof anyway), such
To enable each "instance" of a client application to use a key pair which
is dedicated to the instance, the public key needs to be included in the
DPoP proof. On the other hand, in the scenario you described, all instances
of the client application have to share one key pair. If client application
Hi all,
In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
REQUIRED. However, there are some cases where "jwk" is not necessary in theory.
For example, consider a case where the client is registered with the
Authorization Server, and its one and only public key is also
12 matches
Mail list logo
