Does the client have to sign the software statement, or could a trusted authority sign the software statement instead?

The client could still publish the JWK key set for the signing authority, but instead of a self-signed software statement, the statement can be signed by an authority that may perform additional attestation of the client.

As a practical example, a SPIFFE issuer in an enterprise may check the software bill of materials, deployment environment, image etc before issuing a JWT-SVID which is effectively an identity assertion for the client which might be used as a software statement - https://datatracker.ietf.org/doc/draft-kasselman-oauth-dcr-trusted-issuer-token/

Yes, it can be anything signing the software statement. One method of this is described in https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/

It is convenient to treat the client ID as a URL - the whole CIMD scheme works because of it :).

How would we deal with cases where the client id is not a URL (e.g in enterprises where there may be existing identity infrastructure to assign identities to workloads via SPIFFE for example). Should we treat that as a separate "enterprise auth case", or is there a way to extend the metadata to allow for "alternate client ids" that can be used instead of the client URL (preference is for some way to use the same approach to simplify deployments).

Pre-registered client ID's will always be supported, does that cover this case? so if the ID is not a URL, the AS falls back to looking it up

I'm thinking of the cases where we have seen enterprises deploy SPIFFE (and other similar type solutions). Reverting to manual registration is not scalable in those environments (it is often why SPIFFE gets deployed in the first place - to have a scalable workload identity management system that does not need human intervention).

In those cases, SPIFFE identifiers (they are URIs, not URLs) and credentials (JWTs, X.509 certs) are dynamically assigned (often per instance - something else we should try and figure out with CIMD). This is typically deployed at an infrastructure level, so all workloads in an environment have attested identities and credentials for strong authentication (so a step up from what we get with baseline CIMD in terms of strong auth).

In the case of DCR, the identifier format is not constrained, so the SPIFFE ID could be used as a software statement (there is a draft here: https://datatracker.ietf.org/doc/draft-kasselman-oauth-dcr-trusted-issuer-token/). But with uneven DCR implementation and alternatives like CIMD, it would be valuable if we can find a way to use the CIMD mechanisms without constraining the client ID format (or separate the client id from the location of the client id metadata).

@pcarleton - I had a quick call with @aaronpk and I think we came up with a way to support the above with CIMD. I will write a PR on Aaron's IETF draft tomorrow (let me know if it needs to be somewhere else as well), but I think there is a way to have CIMD work for the above case (well - at least I think we can write a PR to explain the idea ;)).

There is also the potentially simpler option that the desktop application (if it has existing backend infrastructure like Claude Desktop) might choose to offload the authorization to its backend counterpart, in a web-browser.

Of-course that would not work for purely client side applications, but universal-links, on native platforms (iOS, Windows, Android, macOS).

Yea, it's a good point, I'll work that in.

Is this a concern in restricted environments where there may be network restrictions? It may be a topic that is raised earlier

Yes, CIMD will require * egress from some server, which will be more difficult if egress is restricted. Maybe another bullet here? lmk if you have phrasing suggestions