OAuth Virtual Interim Meeting

Date: 22.09.2025

Client ID Prefix and the related Client ID Metadata

https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-prefix/

Aaron starts with his presentation.

Hannes asked about how the client demonstrates possession of the private
key when used with the JWK URL.

Aaron mentions that the use case of native apps will be covered later in
the slide deck. For the use case where the web server acts as a client
this is not an issue.

Hannes asks whether we should revisit the dynamic client registration
specification.

Aaron argues that DCR will be talked about at an upcoming interim
meeting in context of workloads. So, there may be a use case there.

Emelia: A client id metadata document can contain anything. You could
display various aspects to the user - at a minimum the URL but there
could be more, maybe based on the trust relationships.
There are security step-ups that are possible beyond manually approving
it.

Aaron asked whether this answers the question.

Hannes agrees. It mimics the approach published a while ago in the group
related to attestation, see "The Use of Attestation in OAuth 2.0 Dynamic
Client Registration".

Emelia comments on the design of the BlueSky client. Aaron has also been
creating a PoC with FedCM. MCP is also considering this solution instead
of DCR.

Emelia: There was the client id prefix and I have not seen this
functionality in the wild. Is there any AS that supports both features?

Aaron goes back to the example of slide 3. Should there be a prefix on
this client to explain the matching algorithm? If an AS has to support
this document and also OpenID Federation then it has to guess. The idea
of using a URL for the client_id goes back like 12 years.

Pieter: Sometimes the clients may have credentials already. Does the
prefix allow allow to express alternative discovery&matching procedures?
There may be credentials, per instance identifiers, and the meta-data
discovery mechanism. You could express the meta-data separately from the
client id related to the credential. The client id may not be a URL at
all.

Aaron: This is not this mechanism.

Pieter: I am proposing to combine these two ideas.

Aaron: This specification points to the metadata.

Pieter: The dynamic nature of workloads may prohibit there to be any
public keys available already. I would like to re-use the metadata
information for the workload context.

Aaron: You have a 3-part client id: prefix, client id and link to
metadata.

Pieter: yes.
The other idea is to have the client id in the credential but not as a
subject.

Emelia suggests some limits on the path of the client id URL.

Aaron: I want to point out that there is no DDoS attack possibilities
with the client id URL provided to the AS since there is no
amplification.

Brian: This is valuable work providing solutions for a significant
number of deployments. This is work we should consider moving forward.

I am not sure there is a pre-requisitie for the prefix document.

Aaron: There are use cases where this document alone is sufficient and
where there is no need to implement&support the prefix draft. I would
not want to tie one to the other.

Emelia: An open issue is the use of ephemeral client id metadata
documents (e.g. development clients). We currently cannot signal to an
AS that the metadata document is not valid after a certain period of
time.

Hannes: What problems does DCR solve that this document does not solve?

Aaron: Both documents do not support the case with native apps where
there is no attestation support, for example on desktops. Here is a blog
post that offers a good comparison:
https://blog.modelcontextprotocol.io/posts/client_registration/

Rifaat suggests to do a call for adoption after the good receiption of
the draft.

Hannes agrees.

Emelia suggests to solicit from outside communities.

Pieter: Was the call for adoption for the client id metadata or also for
the prefix document?

Hannes+Rifaat: client id metadata