+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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > 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 list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
