On 2020-01-23 22:31, 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.
Hello Brian,
thank you for your efforts in reviewing the IANA registrations.
As for your struggling to understand, we should have struggled more,
since there was indeed a flaw in the reasoning behind the rs_cnf claim
(and introspection parameter). As a result of that we will remove both
the rs_cnf claim and the introspection parameter, keeping only the
rs_cnf token endpoint parameter, which I believe still makes sense.
Background: When introducing the rs_cnf claim, we had mistakenly assumed
that the RS could associate the token with the ongoing (D)TLS handshake
at the time the server certificate message is to be created, this is not
the case and the rs_cnf claim is therefore useless (same goes for the
rs_cnf introspection parameter). Instead I will require that a RS MUST
NOT hold more than one asymmetric key pair based on the same algorithm,
used for authentication. Thus the (D)TLS algorithm negotiation in the
handshake should resolve the issue of which key to use for the RS.
Updates of both draft-ietf-ace-oauth-params and
draft-ietf-ace-oauth-authz coming soon.
/Ludwig
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
