https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-scheme/
Emelia: Would it be better to introduce a client id type?
Aaron: This was the path the OpenID spec went first. The problem is that
it looks good for the Authorization REquest but once you start to
reference the client id in other parts of the OAuth ecosystem, you now
need to reference both parts.
Emelia: If the AS does not know how to resolve the scheme, then it will
fail (if it only understands the HTTPS URLs.
Aaron: If you remove the scheme from the client id, then there could be
misinterpretation by the AS.
Emelia: It would fail anyway.
Aaron: It becomes a problem it is a valid value for another supported
scheme.
Look at the discussion at the Github issue discussion:
https://github.com/openid/OpenID4VP/issues/124
Hannes: Do you expect problems with existing deployments?
Aaron: No, because we describe already existing deployment.
Do I expect that every AS supports this functionality? No, I do not.
The discussion happens in the OpenID Foundation on VCs.
Brian: The idea of defaulting to a type of scheme makes sense. There may
be a need some facility for the client to understand what the default
is. The client needs to know this.
Aaron: Absolutely. But this would be a different document.
Brian: This makes me uncomfortable.
A generalized AS product that supports different resolution mechanisms.
Aaron: There are a few things that are not possible but I believe those
are edge cases. This limitation is described in the document.
Emelia:
Aaron: The client ids would be combined with the issuer URLs. One issuer
URLs would be for one resolution mechanism.
Emelia: Would it be better to prefix the URLs.
Aaron: This would be another approach. The URL approach is a hack. I
wanted to re-use what others already use.
Emelia: This spec is necessary only if you use two different resolution
mechanisms.
Aaron: You could do that but the client has to know that the AS has the
knowledge to differentiate these two cases. We could go this route.
Maybe that is a cleaner way to do it.
Emelia: I think this would be a cleaner way of doing it.
Aaron: I agree.
Emelia: You would have two meta-data parameters: default scheme,
otherwise you have to indicate it (and here is a list of supported
types).
Joseph: The last discussion covered it already. I do not want to rely on
the meta-data because in OpenID VP the wallet only later learns about
that data.
Mike: We had a separate parameter illustrating the URL scheme but Daniel
indicate that this raises security issues. There is going to be a lot of
deployments for federation. We decided not to break it.
At the beginning of the presentation it looked like you are copying the
text from the OpenID VP spec. We should take the existing
implementations into account.
Brian: I think it is strange to call something:something a scheme.
Sometimes it is a prefixed and sometimes it is not. We would be better
off with a prefix separater thing. If we need to account for federation
, we should describe the rules for treating it. The similarity between a
URI and something that is not creates room for confusion.
Aaron: I think they are all URIs. The client id value is not a URI.
Brian: We need to allow for bare HTTPS URI scheme.
Emelia:
Aaron: We are hearing the difference between clean slate vs. taking the
currently deployed design.
Emelia suggesting to use the term "type" instead of value.. Brian and
Hannes agreeing.
Dick: Go back to the motivation slide. Why are we not side-stepping this
discussion and define a new parameter.
Aaron: This does not resolve the ambiguity and will break existing
software.
Dick: It is new functionality. It has to break. The server has to
operate differently anyway.
Pieter: We have to update the server anyway.
Hannes and Aaron discussing how to best approach standardization.
Dick: It sounds like a fairly easy change. While it is deployed, it is
not widely deployed.
Discussion about Wordpress plugin and Mastodon supporting it.