Hi Ben, Since there are multiple experts for this registry, we can ask the others to review the registration.
Thanks, Sabrina Tanamal Senior IANA Services Specialist On Fri Jan 24 01:46:47 2020, ka...@mit.edu wrote: > Thanks for putting the effort in, Brian. > > IANA, do you need to assign a new expert to reviewi the JWT Claims > registration request from this document, or are the experts expected > to be > self-organizing here? > > Thanks, > > Ben > > On Thu, Jan 23, 2020 at 02:31:20PM -0700, Brian Campbell wrote: > > Apologies, I forgot to reply-all at some earlier point and dropped > > the > > mailing lists and other cc's off the thread. Added back now. > > > > And also apologies because I think I need to recuse myself from the > > DE > > responsibility on the JWT registry request here. I've spent more time > > than > > I'd like to admit or really have to spare on it and am still > > struggling to > > understand. > > > > I appreciate you pointing out the authz-info endpoint in ACE but I > > still > > don't follow how "rs_cnf" in an access token would really work in > > practice. > > The client sends the token to the RS's authz-info endpoint on an > > insecure > > connection or one that has the server auth with potentially different > > key > > and the RS stores the access token for later use. Then on resource > > access > > the RS looks up the access token (with respect to the cnf key in it) > > based > > on the key the client used in establishing a new mutually > > authentication > > connection to the RS. For the RS to choose a key for server it will > > use > > during the handshake (and as far as I know the server key is the > > first in > > the authn process of the handshake) based on the "rs_cnf" in the > > access > > token, it needs to remember and associate that client and the access > > token > > with something else (IP address?) that will be available during the > > handshake. It doesn't fit together for me in a way that seems likely > > to > > work or be interoperable but, like I said, I'm really struggling to > > understand. > > > > On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig > > <ludwig.se...@combitech.se> > > wrote: > > > > > Hi Brian, > > > > > > > > > > > > Comments inline. > > > > > > > > > > > > /Ludwig > > > > > > > > > > > > *From:* Brian Campbell <bcampb...@pingidentity.com> > > > *Sent:* den 13 januari 2020 21:22 > > > *To:* Seitz Ludwig <ludwig.se...@combitech.se> > > > *Subject:* Re: [Ace] Requested review for IANA registration in > > > draft-ietf-ace-oauth-params > > > > > > > > > > > > Thanks for the response and updates Ludwig, > > > > > > > > > > > > Please bear with me while I try to wrap my head around some things. > > > > > > > > > > > > The JWT registration request for the "rs_cnf" claim points to Sec > > > 3.3 > > > <https://tools.ietf.org/html/draft-ietf-ace-oauth-params- > > > 08#section-3.3> > > > saying it is "a hint [in the access token] to the RS about which > > > key it > > > should use to authenticate towards the client". But doesn't the > > > client > > > have to go through the DTLS/TLS handshake with the RS (which is > > > presumably > > > when it authenticates to the client) before it presents the access > > > token? > > > I'm not seeing how this would work as seems the RS won't see the > > > hint until > > > after it needs it. > > > > > > > > > > > > > > > > > > [LS] Not in the ACE flow. We use the access token to establish keys > > > at the > > > RS both for the client and the RS. We have therefore defined a new > > > ACE-OAuth endpoint (authz-info) at the RS. The client can POST > > > access > > > tokens to this endpoint without prior authentication. > > > > > > At that point, the RS only validates the signature/MAC by the AS. > > > > > > > > > > > > Later at the time of access, the corresponding token is linked to > > > the > > > access request via the pop-mechanism and the client/access specific > > > parts > > > are validated (e.g. scope, subject). > > > > > > > > > > > > Hope that clarifies things a bit. > > > > > > > > > > > > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig > > > <ludwig.se...@combitech.se> > > > wrote: > > > > > > Hello again Brian, > > > > > > > > > > > > Thank you for reviewing this! Indeed the handling of JWT/JSON > > > interactions > > > was handled sloppily here. I will soon issue a draft update that > > > specifies > > > that the JSON-based interactions should use the syntax from RFC7800 > > > while > > > the CBOR-based ones should use ID.ietf-ace-cwt-proof-of-possession. > > > > > > > > > > > > This correction goes for all the use of “cnf”, “req_cnf” and > > > “rs_cnf”. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Ludwig > > > > > > > > > > > > *From:* Ace <ace-boun...@ietf.org> *On Behalf Of *Brian Campbell > > > *Sent:* den 10 januari 2020 22:12 > > > *To:* Ludwig Seitz <ludwig_se...@gmx.de> > > > *Cc:* Roman Danyliw <r...@cert.org>; jwt-reg-rev...@ietf.org; Jim > > > Schaad < > > > i...@augustcellars.com>; The IESG <i...@ietf.org>; ace@ietf.org; > > > drafts-lastc...@iana.org; Benjamin Kaduk <ka...@mit.edu> > > > *Subject:* Re: [Ace] Requested review for IANA registration in > > > draft-ietf-ace-oauth-params > > > > > > > > > > > > That "rs_cnf" claim registration request in 9.1 points to 3.3 > > > which says > > > it has 'the same syntax and semantics as defined in for the > > > "rs_cnf" > > > parameter', which I think is in 4.1. And 4.1 says that the "rs_cnf" > > > values > > > 'follow the syntax of the "cnf" claim from section 3.1 of > > > [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other comments > > > I've > > > made today, I don't follow what that would mean for the value of > > > the claim > > > when it's a JWT. And that seems like something that's important to > > > understand for the purpose of a JWT claims registry request. > > > > > > > > > > > > > > > > > > On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz <ludwig_se...@gmx.de> > > > wrote: > > > > > > Hello JWT registry reviewers, > > > > > > the IESG-designated experts for the JWT claims registry have asked > > > me to > > > send a review request to you about the "rs_cnf" claim registered > > > here: > > > > > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section- > > > 9.1 > > > > > > Thank you in advance for you review comments. > > > > > > Regards, > > > > > > Ludwig > > > > > > _______________________________________________ > > > Ace mailing list > > > Ace@ietf.org > > > https://www.ietf.org/mailman/listinfo/ace > > > > > > > > > *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.* > > > > > > > > > *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.* > > > > > > > -- > > _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._ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
