Highlight RFC 9207 server support constraint?

[jg10-mastodon-social]

RFC 9207 is only supported by node oidc provider by default since v7.11.0 and CSS only upgraded past this point in v7.0.0. That's still 1.5y ago, so I think it's reasonable to have this requirement but it might be worth documenting that earlier versions of CSS will not work.
I haven't tested other Solid servers, but I don't recall RFC 9207 being an explicit Solid-OIDC requirement, so this might actually be a major Solid compatibility issue?

Another option would be to follow the permitted RFC 9207 leniency: "In general, clients that support this specification MAY accept authorization responses that do not contain the iss parameter"

[uvdsl]

Yeah, we ran into this the other day and had a discussion on Gitter. RFC9207 is not mentioned explicitly in the Solid OIDC spec.

I also believe that RFC9207 is phrased in a way that if a server provides the iss URL parameter, then it needs to be checked. If it is not provided, then nothing happens.
I do need to double check this though.

Do you run into issues with this right now?

[jg10-mastodon-social]

I need to upgrade my personal CSS server to be able to use this library 😉
That's not a deal-breaker for me, but I can imagine that it will limit adoption for client developers wanting to support existing non-RFC9207 compliant servers.

Avoiding mix up attacks does seem desirable but it looks like other features of Solid-OIDC might already mitigate against them?
"There are also alternative countermeasures to mix-up attacks. When an authorization response already includes an authorization server's issuer identifier by other means and this identifier is checked as laid out in Section 2.4, the use and verification of the iss parameter is not necessary and MAY be omitted. For example, this is the case when OpenID Connect response types that return an ID Token from the authorization endpoint"
i.e. your id token check might already be sufficient even if the iss query param is missing?

[uvdsl]

Yes, I think that may be the case - but I am not too familiar with the details.
There was the initial discussion in solid/solid-oidc#221 which resulted in the adoption of RFC9207.

Anyways, I think that supporting RFC9207 would not hurt if it was along the lines of "if the URL param is provided, then check it". And, I would impose the requirement for RFC9207 on Solid IDPs. It is not that hard to implement.

The ID token check is mandatory for security in any case, I think.

[gibsonf1]

Anyways, I think that supporting RFC9207 would not hurt if it was along the lines of "if the URL param is provided, then check it". And, I would impose the requirement for RFC9207 on Solid IDPs. It is not that hard to implement.

TrinPod now also supports iss (as of this week) - just heard about it from Angelo Veltens

[uvdsl]

Is anybody aware of any other server implementations (besides NSS) that do not support RFC 9207?
(@jg10-mastodon-social, @angelo-v)

I am only aware of NSS, CSS/Pivot, TrinPod, and ESS. All of the Pod Providers seem to use one of these implementations. (Digita seems to be MIA).

Edit: Does anyone have experience with the Nextcloud plugin? @Potherca, perhaps? 🙂

[jg10-mastodon-social]

As one would expect with a spec with sufficient attention and breaking changes, there's a number of implementations that were deliberately experimental or appear to be unmaintained e.g.
https://github.com/NoelDeMartin/lss
https://github.com/ontola/dexpod
https://github.com/pdsinterop/php-solid-server

[Potherca]

The pdsinterop/php-solid-auth package handles OAuth2, OpenID and OIDC for Solid request for the Solid Nextcloud plugin and the Standalone PHP Solid Server.

From what I can see, the issuer iss is added to the JWT token, but not the 302 response Location URL.

So, no, we do not (yet) support RFC 9207.

However, I do not see any reason for us not to add RFC9207 support on the very short term. We've got a new round of development updates planned for the comming month. Might as well include RFC9207, correct?

[uvdsl]

Thank you for considering this. That would be awesome if you'd add support for that. I really do think it is a super small and easy thing to include the iss query parameter alongside the authorization code 👍