Simplify passing the public key to the RP

[David W Chadwick]

The existing proposed method of sending the public key from the SIOP to the RP is not optimum. It requires creating the hash of the public key and then sending the public key alongside it.

Section 3.4 of RFC 7638 describes how it works. First a hashing algorithm has to be agreed out of band, then data canonicalisation has to be performed. Both of these steps can lead to grief.

Then the public key has to be obtained and the recipient recompute the hash and see if it matches the received hash.

I would therefore propose a much simpler and less error prone method for sharing the public key as a URI, namely, the key holder takes the JSON specification of the public key as specified in RFC 7517 then base64 encodes it. The recipient simply base 64 decodes the structure and ends up with the JWK. No canonicalisation is needed because the recipient gets the JSON object the sender encoded. No hashing algorithm has to be agreed out of band.

The public key can be made into a URI in a similar fashion to the thumprint e.g.

• urn:ietf:params:oauth:jwk:<base 64 encoding public key parameters>

‌

[Kristina Yasuda]

Discussed during 2021-12-16 SIOP call

[David W Chadwick]

At the meeting today it was stated that the subject identifier should be the same value each time if the RP is to identify the same user each time. Using base64 of the jwk does not guarantee that the subject identifier will be identical each time, as JSON can reorder the properties, so the base64 would be different.

The solution to this is proposed as follows: the RP takes the base 64 encoded subject identifier, base 64 decodes it, then uses its own canonicalisation and hashing algorithm to produce its own unique subject identifier. The advantage of this is that the standard no longer needs to specify the hashing and canonicalisation algorithms and RPs can do their own thing (although the standard can suggest that the existing algorithm may be used). The disadvantage of this approach is that RPs might screw this up - but if they do screw this up then they would not be able to use the existing hashed key id approach anyway, as they would not be able to reproduce the hashed subject id from the sub_jwk they are given.

‌

[Kristina Yasuda]

First, I agree that to use JWK Thumbprint, hashing algorithms need to be agreed. I don’t agree with a proposed solution to use base64url encoded JWK as an alternative.

The chances RP messes up setting up their own canonicalization rules for the Base64url encoded JWK are higher than messing up hashing the sub_jwk. We could add base64url encoded JWK as an option, but I do not think we should do it from the interoperability perspective. I prefer we focus on improving simples JWK Thumbprint option.

My suggestion would be to add Registration/Discovery parameter to pre-agree on the JWK thumbprint hashing algorithm, and say that if such parameter is not included SHA256 must be used. I will do a PR that does this. since this is the issue we need to address regardless of whether we decide to add base64url encoded JWK as an option or not.

[Kristina Yasuda]

PR #93

[Michael Jones]

As discussed in yesterday’s call, a full JWK with all the optional fields and no defined field order is probably not a good stable subject identifier. A JWK Thumbprint is.

[David W Chadwick]

Given that the sender creates the JWK thumbprint from the full JWK, and it is stable for the sender, then it is obvious that the receiver must be able to perform the same transformation in order to recover the same stable JWK thumbprint. The difference between the current JWK thumbprint method and the proposed base64 method, is that in the former case both the sender and recipient must perform the same thumbprint algorithm on the full JWK, whereas in the base64 case only the recipient needs to perform the thumbprint algorithm. So it seems to me that the base64 method is a) more efficient and b) provides the recipient with more flexibility

[Kristina Yasuda]

agreed to close on July 28th SIOP call when closing JWK URI PR #127