Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Dick Hardt <[e-mail]>]

+1

KISS
ᐧ

On Tue, Sep 8, 2020 at 3:55 PM John Bradley <[e-mail]> 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 necessary. And while omitting the key in such cases
> would reduce the size of some messages (the DPoP proof anyway), such
> optionality would add complexity to implementations and deployments (and
> that kind of complexity can and often does degrade interoperability and
> even security). How, for example, would a client know if the access token
> includes the public key and thus whether or not to include the key with the
> proof? Sure the access token could always include the key (rather than
> thumbprint) but then there's the question of how to get the key to the AS.
> As well as the stated desire to utilize the same DPoP Proof structure for
> requests to both the AS and RS. There will be some clients that have public
> key(s) registered and some that won't (maybe a lot that won't as a driving
> use case for many for this is key binding access and refresh tokens for
> public clients). The protocol defined by the draft needs to account for
> both.
>
> Ultimately there are a number of different ways the necessary data could
> flow through the various protocol elements. And there are some tradeoffs
> with different approaches and/or trying to accommodate variations under one
> approach. The approach the draft has taken thus far is to prioritize
> consistency and simplicity as much as is possible. And that ethos has led
> to how it's currently defined, which is to always include the key in the
> proof and bind to a hash of the key in the access token.
>
>
> On Tue, Sep 8, 2020 at 3:29 AM <[e-mail]> wrote:
>
>> 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 registered
>> with
>> the AS. In that case, when the AS receives a request on Token endpoint,
>> it can
>> just use the public key registered for the client to verify the DPoP
>> Proof.
>> There is no need to send the public key in DPoP Proof.
>>
>> The same goes for requests to the Resource Server, if the AS and RS share
>> the
>> storage for clients' public keys. Things are a little difficult if the AS
>> and RS
>> are separate. Probably the Access Token or its introspection result have
>> to
>> include the public key (instead of its thumbprint as described in section
>> 7).
>>
>> If the client registers multiple keys with the AS, it needs to specify
>> which key
>> it uses to sign the DPoP Proof. However, there is still no absolute need
>> to send
>> the whole key in DPoP Proof. Instead, the client could use "kid" header
>> parameter to specify the key.
>>
>> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1],
>> but I'm
>> not sure what happened to the discussion. There was also a comment on the
>> latest
>> draft about the "jwk" header parameter [*2]. I agree with using the same
>> DPoP
>> Proof structure for requests to AS and RS, but I think there are some
>> cases
>> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would
>> allow
>> those cases to reduce some messaging overhead.
>>
>> I'd like to hear your opinions about it.
>>
>>
>> [*1]:
>> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
>> [*2]:
>> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>>
>>
>> Best regards,
>> Toshio Ito
>>
>> -------------
>> Toshio Ito
>> Research and Development Center
>> Toshiba Corporation
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>