Client Identifier Prefix and URL ambiguity

I realise there has historically been a flurry of Client Identifier Prefix/Scheme related issues (#505, #376, #351, #554, #466, ...) but I think there is one issue remaining

There is a longstanding understanding of the necessity within an OAuth 2/OpenID Connect environment of preventing confusion between client IDs and User/Subject IDs. For example, RFC 9068 says

Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. For example, if the authorization server elects to use the client_id as the "sub" value for access tokens issued using the client credentials grant, the authorization server should prevent clients from registering an arbitrary client_id value, as this would allow malicious clients to select the sub of a high-privilege resource owner and confuse any authorization logic on the resource server relying on the "sub" value. For more details, please refer to Section 4.14 of [OAuth2.Security.BestPractices].

To prevent cross-JWT confusion, authorization servers MUST use a distinct identifier as an "aud" claim value to uniquely identify access tokens issued by the same issuer for distinct resources. For more details on cross-JWT confusion, please refer to Section 2.8 of [RFC8725].

Authorization server implementations may put client IDs in the sub (client credentials grant), client_id (RFC 9068 style access tokens), and aud (OIDC ID tokens) claims. In addition they may put relying party identifiers, typically URLs, in the aud cliam of both access tokens and ID tokens.

To put it simply: an OAuth 2.0/OIDC implementation may already be using URLs as identifiers in ways that could cause confusion with the client identifier schemes introduced in this specification. As defined at present, there is no way of identifying whether the prefix is a Client Identifier Prefix or a URL scheme.

Except, for all but one of the prefixes defined by this document, it is in fact possible to distinguish these two. RFC 3968 defines a URI scheme as:

      scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

All of the Client Identifier Prefixes defined in OpenID4VP other than origin contain an underscore, rendering them an invalid URI scheme. If the origin prefix were changed to e.g. web_origin, then the Client ID prefix syntax could be defined as e.g. the regex [a-z][a-z0-9]*(_[a-z0-9]+)+ making the two mutually exclusive.

JWT defines the syntax of the identifier claims as StringOrURI:

StringOrURI
      A JSON string value, with the additional requirement that while
      arbitrary string values MAY be used, any value containing a ":"
      character MUST be a URI [[RFC3986](https://www.rfc-editor.org/rfc/rfc3986)].  StringOrURI values are
      compared as case-sensitive strings with no transformations or
      canonicalizations applied.

This implies that no existing valid user can have subject identifiers in conflict with client identifiers defined with a client identifier prefix. Technically OpenID4VP JWTs are invalid per the JWT spec; but OpenID4VP can be said to be extending the specification here.

When @aaronpk brings his client-id-scheme draft back to the oauthwg, presumbaly it would establish a registry of such schemes and note the restriction that they must contain an underscore to render them illegal as URI schemes.

Start by reviewing the client identifier prefix definitions in the OpenID4VP specification alongside RFC 3986 URI-scheme syntax and the cited JWT rules. Decide whether the origin prefix should become web_origin, and define the registry or syntax restriction needed to keep prefixes distinct from URL schemes; the specification and related issues should reflect the settled choice.