[Openid-specs-ab] Issue #1683: Opt-In to Credential Issuing (openid/connect)

[Thomas Bellebaum]

New issue 1683: Opt-In to Credential Issuing
https://bitbucket.org/openid/connect/issues/1683/opt-in-to-credential-issuing

Thomas Bellebaum:

# Story time

Who would you expect to be the entity behind `issuer` “https://bellebaum.eu/bramm/”? \(does not exist\)

A random programmer as well as any user would probably have a look at the authority \([bellebaum.eu](http://bellebaum.eu)\) and guess that the person owning the domain and operating the server is also the issuer. This has the consequence that any misuse by the actual issuer may have direct negative consequences for the trust towards [bellebaum.eu](http://bellebaum.eu).

A server operator lending part of their Path to another actor \(e.g. think hosting services or student directories at universities\) may thus want to prevent credential issuers from operating on one’s server.

This is possible currently to some extend. For instance, one could block any request including “vc-credential-issuer” or whatever in their path, thus preventing any automated discovery.

The problem with this approach is that it is essentially an “Opt-Out”, a way to fix any problems after the fact. I believe that the vast majority of hosting services has never even heard of “OpenID” or “OpenID4VCI”.

# A well-known solution

`.well-known` URIs are constructed in a very clever way to enable “Opt-In”. Since the path segment of a URI essentially follows a tree-like structure, it cuts off a single branch in that tree which server operators have to be aware of and which any application should register subtrees for provided they require the server operator to be aware of any use of these subtrees. You cannot host an EST-Server on someone else’s server, you cannot acquire a certificate for a domain via ACME there, and you cannot perform RFC 8414 Authorization Server Metadata Discovery there, unless the server operator allows for it, e.g. by relaying any requests to some of the paths controlled by you \(This is usually fairly easy. E.g. `NginX` has a `rewrite` directive for exactly this purpose\).

# Alternatives

I acknowledge \(although I would have voted against it\) that this WG does not want to use the RFC 8615 well-known URIs, instead going for the OIDC style “Variant of well-known” \(which RFC 8615 _explicitly_ does not define, c.t. Appendix A\).

In this case though, the fact that the `issuer` authority may be unaware of \(and for that reason maybe shouldn’t be held liable for\) and issung on their servers should be documented to at least give server operators something to point to.

Preferrably, there should be an explicit Opt-In to allow for issuing built into the spec in some other way. \(E.g. @David Chadwick didn’t you do something DNS-related for managing trust infrastructures? I am unsure whether this could be used here\)