+1 KISS ᐧ
On Tue, Sep 8, 2020 at 3:55 PM John Bradley <ve7...@ve7jtb.com> 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 <toshio9....@toshiba.co.jp> 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 >> OAuth@ietf.org >> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
