Does not work with NSS on solidweb.org

[angelo-v]

Hi, just noticed that signing in with solidweb.org (which runs NSS) does not work with this library. It gives an internal server error due to the used ES256 algorithm ("id_token_signed_response_alg":"ES256"), it only seems to work with RS256.

I am not sure what the solid spec mandates, and how the correct algorithm would be determined, or if NSS is just outdated on that point and support is dropped deliberately.

[jg10-mastodon-social]

In the specs included in https://solid.github.io/solid-oidc/ the default, and SHOULD appears to be RS256, so it would be useful to justify and document the deviation.

In 8.1.1. ID Token Validation

An ID Token must be validated according to OIDC-CORE, Section 3.1.3.7

https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

The alg value SHOULD be the default of RS256 or the algorithm sent by the Client in the id_token_signed_response_alg parameter during Registration.

In 5.2 OIDC registration

For non-dereferencable identifiers, the Client MUST present a client_id value that has been registered with the OP via either OIDC dynamic or static registration. See also [OIDC-DYNAMIC-CLIENT-REGISTRATION].

https://openid.net/specs/openid-connect-registration-1_0.html

id_token_signed_response_alg
OPTIONAL. JWS alg algorithm [JWA] REQUIRED for signing the ID Token issued to this Client. The value none MUST NOT be used as the ID Token alg value unless the Client uses only Response Types that return no ID Token from the Authorization Endpoint (such as when only using the Authorization Code Flow). The default, if omitted, is RS256. The public key for validating the signature is provided by retrieving the JWK Set referenced by the jwks_uri element from OpenID Connect Discovery 1.0 [OpenID.Discovery].

---

It looks like this relates to CSS compatibility?
CommunitySolidServer/CommunitySolidServer#1181 (comment)

---

Given the title of this issue, the effect of #12 on NSS login would also need to be confirmed.

[jg10-mastodon-social]

Looks like id_token_signed_response_alg should be negotiated
inrupt/solid-client-authn-js#1274

So having the client provide a single algorithm not supported by the server would be a bug?

[angelo-v]

In the specs included in https://solid.github.io/solid-oidc/ the default, and SHOULD appears to be RS256, so it would be useful to justify and document the deviation.

Cannot find this, can you quote the spec or link to the section?

[jg10-mastodon-social]

I've updated the comment above with the relevant quotes across the three specs 🙂

[jg10-mastodon-social]

Relevant NSS issue is nodeSolidServer/node-solid-server#1702

It includes the comment "The openid spec requires that all IdPs support /at least/ RS256 (for a baseline). So, my recommendation is - NSS should support both algorithms."

So my take is:

• NSS is fine but could add support for ES256 to align with CSS (and others apparently)
• CSS should really be supporting RS256 for id token signing according to the OIDC specs, but it seems there was a discussion that agreed to move to ES256 anyway
• This library should really be checking id_token_signing_alg_values_supported but doesn't need to if it uses RS256 and servers comply with the OIDC specs or if the consensus is actually for Solid servers to use ES256 (and this ends up documented somewhere)

[jg10-mastodon-social]

My understanding of the change required in this library is that an algorithm should be selected in redirectForLogin after fetching openid_configuration and then passed to requestDynamicClientRegistration.

solid-oidc-client-browser/src/AuthorizationCodeGrant.ts

Lines 46 to 49 in 1792a75

	await requestDynamicClientRegistration(
	registration_endpoint,
	client_details as DynamicRegistrationClientDetails ?? { redirect_uris: [redirect_uri_sane] }
	)

solid-oidc-client-browser/src/DynamicClientRegistration.ts

Lines 15 to 22 in 1792a75

	const client_registration_request_body = {
	...client_details,
	grant_types: ["authorization_code", "refresh_token"],
	id_token_signed_response_alg: "ES256",
	token_endpoint_auth_method: "none",
	application_type: "web",
	subject_type: "public",
	};

And the irony in all this is that it seems that despite the Solid-OIDC spec referring to the id token with UMA, I don't think any servers use it at all at the moment, so it seems no other changes to this library are needed - we just need the server to validate the request 🤯

[uvdsl]

Thanks to both of you!
I guess switching to RS256 (as mandated by the Solid-OIDC spec) would be the easiest solution.

re UMA, indeed, the current implementations do not support the UMA flow yet (except ESS which does support UMA... obviously...). The CSS crew is working on supporting it afaik.

If/When UMA becomes more prominent in the ecosystem, I guess I will have to extend this library to also support that flow.
But there are quite some open questions on the management of the access tokens (when to use which etc) on my side at least. We will see.

[uvdsl]

Hi, I was looking into this and was simply trying to substitute ES256 for RS256 both in the client_id document and for dynamic registration.

Upon trying to log into my account at a CSS, I received a 400 error message:

{
"name":"InvalidClientMetadata",
"message":"invalid_client_metadata",
"statusCode":400,
"errorCode":"H400",
"details":{},
"error":"invalid_client_metadata"
,"error_description":"id_token_signed_response_alg must be 'ES256'"
}

And indeed, for id_token_signing_alg_values_supported CSS only lists ES256 while NSS and TrinPod only list RS256. ESS supports both (but upgrades silently from RS256 to ES256).

So, let's approach the CSS devs and have them include RS256, I guess?

[uvdsl]

You are way ahead of me.
Linking CommunitySolidServer/CommunitySolidServer#2055 again...
And solid-contrib/pivot#113 ...

[uvdsl]

By the way, once the signing algorithm issue is sorted out, we run into #12 as NSS does not implement RFC 9207, see nodeSolidServer/node-solid-server#1830.

[bourgeoa]

@uvdsl NSS webid scope is now working (publish is under review)
you can check on NSS https://pivot-test.solidweb.org:8443 (I now the name is not funny for NSS tests) by running solid oidc conformance tests
https://solid-contrib.github.io/solid-oidc-tests/

By the way should I add support for both signing alg RS256 and ES256 ?

[uvdsl]

@bourgeoa, thank you for the hint! Will do.

re signing alg, if this is not too much of an issue for you, that would be nice. However, I found that if a client simply omits id_token_signed_response_alg in thier registration/client id document, the server will simply use whatever the server is configured to use. And then, because my library simply checks validity of the token, the signing alg is actually not that relevant in the end. But it would be a nice to have - and I will simply remove the explicit demand for a specific signing alg from the dynamic registration attempt.

the major problem to tackle would be adding RFC 9207 (as discussed in #12 and nodeSolidServer/node-solid-server#1830), i.e. adding the iss as query parameter alongside the code upon redirect after authentication.