How does a wallet discover if an OID4VCI issuer uses federation for a credential offer?

[TimoGlastra]

I've seen a lot of different discussion across a lot of repositories around OID4VCI / Federation, so if this has already been discussed please point me to the discussion and I will close this.

In all flows about OID4VCI / federation it has been described that the wallet gets a list of issuers beforehand. But in the case where you get an offer from an issuer you haven't interacted with before. How would a wallet know that the issuer uses Federation, especially that it intends tot use it for that interaction?

I think the 'dumb' approach would be to try to fetch the federation metadata, we already do this for:

• openid configuration
• authorization server metadata
• openid credential issuer

Is this the recommended approach and is it not needed to indicate this beforehand?

For OID4VP it is explicitly described. I'm not sure if this should be described in OID4VCI or the Federation for wallets specs?

[peppelinux]

Yes, we need a specific example for the credential offer flow.

the offer would use an object like this: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-4.1.1-5
the key element is the credential issuer unique identifier, provided using the credential_issuer parameter.

The wallet instance therefore has everything to start a discovery flow, like the one described here: https://openid.github.io/federation-wallet/main.html#section-8.3-6

without an issuer id scheme, like the one proposed in openid4vp, it is required for the wallet unit to "guess" the openid-federation and if absent try another discovery mechanism. The point would therefore go to how many discovery mechanisms (and trust frameworks) a real world wallet unit is requested or supposed to support and use

[TomCJones]

Why not just ask if the issuer can respond to any query to .well-known/openid-federation endpoint

[TimoGlastra]

@TomCJones yes i think that is the 'dumb' approach i tried to describe. Just wanted to make sure whether that is the right direction. But also looking at @peppelinux his answer, it seems it is.

[peppelinux]

@TomCJones @TimoGlastra indeed, trying to get the .well-known/openid-federation represent a technical way to guess the credential issuer support of openid federation

[selfissued]

This was discussed during the 12-Dec-24 working group call. The question was asked whether, perhaps in some cases, a metadata value might be available saying that Federation is being used before .well-known/openid-federation is tried. Of course, if that were true, there would be two metadata sources about the same Entity in a role, which has its own downsides.

[samuelmr]

Suppose ACME University (acme.edu.example) is issuing academic credentials using a service provided by a third party (techprovider.example). The credential_issuer endpoint is https://techprovider.example/credentials/

If a wallet user needs to decide whether to accept a credential from ACME University, the wallet should query https://techprovider.example/credentials/.well-known/openid-federation for the OpenID Federation configuration, right?

The credential endpoint is the most natural place to query for the keys the issuer uses to sign credentials. On the other hand, techprovider.example may issue credentials also on behalf of other organizations (using the same endpoint). It might be difficult for them to serve different federation configurations on behalf of all their customers.
The education sector trust anchor (ministry.edu.example) would want to state that acme.edu.example is a valid issuer of higher education credentials. Thus ACME University is a part of the federation, but their service provider is not.

The credential offer (shown to the user in the ACME University's service) has ways for ACME University to specify locations of all kinds of endpoints (credential_issuer, authorization_server) enabling the university to manage their IT in flexible ways. However, if the credential offer is shown as a QR code on their service, there is no way for the wallet to know where to fetch the University's openid-federation configuration.

I would like to see a way for ACME University to also specify the location of their openid-federation configuration in the credential offer.

[peppelinux]

@samuelmr, I want to start from this example: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-4.1.1-6

"credential_issuer": "https://credential-issuer.example.com", configures the entity that plays the role of credential issuer.
once this information is made available, discovery the trust with this entity may happen in several ways, according to the supported trust frameworks. For instance using openid federation, if the credential issuer supports it.

The evidence if https://credential-issuer.example.com supports openid federation can be obtained by trying to fetch https://credential-issuer.example.com/.well-known/openid-federation.

There might be other mechanisms like navigating a federation through the subordinates or trust marked listings or using resolve endpoints. In anyway, https://credential-issuer.example.com/.well-known/openid-federation must always be provided by the credential issuer.

if a qr-code is provided for the credential offer, the credential_issuer member must always be present within the payload, since it is REQUIRED.

a credential issuer enabled in issuing credential on behalf of other organizations should be able to proof to be a legitimate issuer for those credentials owned by other organizations. Trust marks, if defined within the trust framework and enabled by the Trust Anchor, represent from my perspective the best approach to satisfy this need.

wdyt? A PR should be provided to finalize the best approach.

[samuelmr]

If the issuer uses a SaaS platform for issuance, the SaaS provider should not be able to prove to be a legitimate issuer – just a technology service provider.

I think it should be possible to outsource the issuance to a technology provider's SaaS service. Or do we want to mandate that organizations must self-host their issuer software?

If we agree that a technology provider can offer the issuance software as a service, what is the best way to inform the user who's issuing what?

Authorizing tech providers to be legal issuers:

• The legal issuer's Superior Entity publishes a statement that credential-issuer.example.com is a trusted issuer of higher education credentials

While this is a simple solution, I don't think it is practical in many cases. If there is regulation or a ruleset specifying who is a bank, a university, a health care provider, etc., the Superior Entity may not be able to legally state that the technology providers of these organizations are actually members of the federation.

Using domain name mapping:

• The legal issuer creates a CNAME entry in their DNS pointing to the tech providers service so that it seems to be in the legal issuer's domain (credentials.university.edu.example -> credential-issuer.example.com)
• The legal issuer's Superior Entity publishes a statement that credentials.university.edu.example is a trusted issuer of higher education credentials
• The SaaS provider configures their software so that when the service is accessed using the hostname credentials.university.edu.example, .well-known/openid-federation returns a custom entity configuration for the university

This is somewhat cumbersome to implement and makes it even harder for the technology providers to work with OpenID Federation.

Including a pointer to the federation configuration in the credential offer:

• In the same way that the credential offer can direct the wallet to different endpoints for credentials, tokens, etc., it could tell the wallet where to find the (legal) issuer's federation configuration.

How would you write a spec that uses trust marks to solve the issue?

[surfnet-niels]

@samuelmr I think you question is very valid, however, I also think they are perhaps a new topic?

I would guess based on statements above in the response to the question from @TimoGlastra on discovery of the use of OID Fed is in some way based on going to a specific URL endpoint where the .well-known/openid-federation is published.
@selfissued askes if another statement would be needed, which in my opinion would not yield anything as generally speaking it would be as expensive to query that other thing as compared to queriying .well-known/openid-federation, but the latter would ofcause be much more efficient in case we do actually have an endpoint there.

Your question is about what URLs should be used in case of multi tennant, proxy or something similar. And indeed this is a very common use case I think, at least in my world where we have many proxy solutions sometimes even on a national level where there is one proxy to serve the authentication needs for all research and education institutions in the country.

I am wondering however if this is actually a problem for OID Fed or for OpenID4VCI protocol. Both mandate the direct relation between the entity entifier and the path to the ./well-known files. Neither however make any statements on the organisational relation between ACME University (acme.edu.example) and techprovider.com. So from specification it is totally fine if techprovider.com is publishing a ./well-known/openid-federation infomation where it claims to be ACME University issuer.

If that is actually "trusted" behaviour is a whole different question however, which very much depends on the rules of the federation. The TA could at registration time mandate the entity configuration must live at a specific domain where ACME University can prove ownership (which by the way still does not mandate the need for it to be https://acme-university.edu).

In our use case we are actually considering to handle federation membership registration based on the presence of a Trust Mark. Basically the Trust Mark is the endresult of an organisational registration process for an institution, e.g. ACME University. It is handed to the organisation in an out of band way. When the org now wants to technically register an Entity at our TA, we simply check for the presence of this trustmark in the entity configuration. This way we now do not need to depend on e.g. strong binding between the org and a URL

[peppelinux]

@samuelmr using an intermediary providing an entity configuration on behalf of another entity would match the SA full defined in the italian implementation, defined here:

https://docs.italia.it/italia/spid/spid-cie-oidc-docs/it/versione-corrente/soggetti_aggregatori.html

You can use the full intermediary to get a federation interface and make everybody building the trust chain about its subordinates, while the endpoints of the subordinates would point to others hostnames, domains or simply webpaths.