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) 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.

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)

[David W Chadwick]

@Thomas. I understand your problem. The current spec does allow paths to be used and therefore a student could run their own credential issuer. But that is OK, because according to W3C VC DM anyone can be a credential issuer.

So it then boils down to “who is trusted to be a credential issuer”. Well, the girlfriend of the student might indeed trust the student to issue her with a VC. And the VC DM allows this. However the VC DM does not provide any mechanism (other than out of band configuration) for how this might be achieved. This is where the extensions I have defined to VCs and to the OIDC4VP protocol come into play. They allow the various entities to automate the process of who is trustworthy by using a trust infrastructure. (OpenID Federation is one such method, TRAIN is another, and YES.COM has its own proprietary mechanism, to name 3 of them).

VCs add the trust schemes they are a member of, to the VCs they issue. Recipients check this by calling their trust infrastructure. This method is now documented in the implementation consideration section of OIDC4VPs.

RPs send a message (see PR#255 for details) to the wallets saying which trust schemes they are a member of and the wallets check this by calling their trust infrastructure. We need to accept this PR and then I believe it solves your issue.

[Thomas Bellebaum]

@David I agree, at least for W3C VC DM, although some specs/drafts in the field (e.g. DID Web) do have differing semantics.
But does this imply that OpenID4VCI is only targeted at Credential Formats where the issuer identifier is not considered to carry any information other than to indicate a way of resolving cryptographic keys? Or more precisely, where the authority in the value of issuer is not by itself used to determine trust in an issuer.

If I wanted to use another format than W3C VCs, would I need to care about this? If so, it should at least be documented, and to guarantee the generality of OpenID4VCI, either

• OpenID4VCI should define an Opt-In mechanism, or
• OpenID4VCI should describe when an Opt-In mechanism may be necessary for other/future supported formats and mandate that they be specified by extensions to OpenID4VCI

‌

[David W Chadwick]

The proposed solution does not affect the OIDC4VCI protocol. The only protocol affected is OIDC4VPs and the proposed enhancement works regardless of the format of the requested credential.

If the credential is not a W3C VC, then it will need to define its own mechanism for specifying the trust infrastructure(s) it is a member of. Adding this information to the OIDC4VCI protocol will not help the verifier since it does not use this protocol. This is why the information is embedded in the VC and signed by the issuer so that it is available to everyone who receives the VC.

[Thomas Bellebaum]

This is exactly my point. Say another credential type does define its own trust infrastructure, and this infrastructure references the authority in some issuer like claim.

The people defining credential formats are not necessarily the ones specifying exchange protocols (and there are issues with this all over the place), so they might not even be aware that some spec called OpenID4VCI might have a problem with this.

But people with their wallets supporting the WG SSI-specs will probably still want to use the new format (and with the already implemented protocols), and now we have exactly the problem I am talking about above.

[David W Chadwick]

Sorry you have lost me. Could you please restate the problem that you envisage. From my perspective, if the new credential format includes its own trust infrastructure references inside it in an issuer claim, then it will work exactly the same as now with OIDC4VCI (since OIDC4VCI is independent of the credentia format.) The proposed enhancement to OIDC4VPs is also independent of the credential format (and trust infrastructure) so it should also work with the new credential format (and trust infrastructure) as well. So what is the problem?

Every component (Issuer, Wallet, Verifier) that wants to work with the new credential format and new trust infrastructure will need to understand and recognise them, so I do not see that this is a problem, do you?

[Kristina Yasuda]

I am sorry, I do not understand the problem. Could you please restate which entity will have which problem?

there is a fixed URL for the credential endpoint and metadata.

[Kristina Yasuda]

Closing due to the lack of activity and clarity. Please comment if anyone disagrees - happy to reopen