Binding Issuer to a service provider that the Issuer is using to host Issuer Metadata

[Sakurann]

Current spec is written under the assumption that the issuer hosts the metadata itself. meaning that the entity whose metadata can be found at the path formed based on credential_issuer identifier URL is also the owner of that URL. However, the Issuer might be using managed services to host Issuer metadata. In which case, Entity A (actual issuer)'s metadata is being hosted under domain of an Entity B that provides that managed service.

The issue we are facing is how to communicate to the wallet Entity A's domain/identifier so that it could be displayed to the user when obtaining user consent to get the credential issued.

One option we explored is to sign the metadata using the key controlled by Entity A. In our case, that key is expressed using a DID (did:web) so that the wallet obtains the key from a DID Document and also discovers a JWS signed by us that attests the binding between the DID of entity A and entity A's domain. which i realize is a lot...

Maybe alternative could be, including domain of the actual issuer in the issuer metadata that is hosted by another entity B? I don't think this needs to be per credential, so could probably be a new top-level issuer_domain parameter

[David-Chadwick]

"Maybe alternative could be, including domain of the actual issuer in the issuer metadata that is hosted by another entity B?"
I don't see how this can work as it will allow anyone (B) to masquerade as being the owner of A's metadata

[jogu]

The issue we are facing is how to communicate to the wallet Entity A's domain/identifier so that it could be displayed to the user when obtaining user consent to get the credential issued.

Relying on a user verifying that the displayed domain name is the expected one has proved to be a bad pattern.

That aside, I'm struggling to see what is the issue here that's a new problem in VC? Hosted openid connect providers have been around for a long time, usually relying on the customer setting entries in their DNS to point at the IP of the hosted services provider?

[Sakurann]

@David-Chadwick you are right. so I think signing the request with B's key seems to be the only option

[Sakurann]

@jogu

Relying on a user verifying that the displayed domain name is the expected one has proved to be a bad pattern.

maybe it is not ideal, but it's the most basic way. just like users are expected not to type in their credit card information when the SSL cert has not been verified or http is used.

That aside, I'm struggling to see what is the issue here that's a new problem in VC? Hosted openid connect providers have been around for a long time, usually relying on the customer setting entries in their DNS to point at the IP of the hosted services provider?

we really want to avoid the customers to need to change their DNS settings, and there seems to be a simpler way. OpenID Federation spec mandates signing of the metadata hosted under the domain - there are other use-cases for signing the metadata.

[David-Chadwick]

@Sakurann I think you mean signing with A's key is the only option

[jogu]

maybe it is not ideal, but it's the most basic way. just like users are expected not to type in their credit card information when the SSL cert has not been verified or http is used.

We kind of don't expect users to check that though, as their credit card provider will refunded for any fraudulent transactions. Passkeys/FIDO/etc came about because the user can't be relied on to make this kind of check.

we really want to avoid the customers to need to change their DNS settings

I'm not sure this is a big issue - customers are expected to change their DNS settings when using managed email services, managed web hosting, when they need other services to be able to send emails on their behalf, etc. Requiring it for issuance services as well doesn't seem unreasonable to me. DNS is a good established way to associate services to a domain, I'm unconvinced spending working group time inventing & securing an alternative way to demonstrate ownership of a domain is worthwhile.

[Sakurann]

let me rephrase the issue we are looking for a solution to solve: "there is a need to bind the “technical endpoint” hosted by the service provider to the domain of the company using that provider to be able to show the latter as trustworthy information to the user."

[Sakurann]

I think you mean signing with A's key is the only option

yes!

[Sakurann]

Discussed at IIW with @tlodderstedt @jogu @decentralgabe and others. Current proposal is the following:

issuer metadata contains a parameter that contains domains or DIDs of the actual Issuer who is using service provider to host its metadata (we have been using a placeholder name on_behalf_of for this parameter).

1. when the actual issuer's identifier is an https url, on_behalf_of contains that url. the wallet appends a path .well-known/authorized_providers (also a placeholder path we have been using during discussions) and obtains a JSON object that contains service provider's domain.
2. when the actual issuer's identifier is a DID (Decentralized Identifier), on_behalf_of contains a JWS string, where the actual issuer signed over both service provider's domain where the issuer metadata is hosted and its own DID. the key to validate this signature is obtained from the DID Document of the issuer's DID. the binding between issuer's DID and issuer's domain is established using DIF Well Known DID Configuration spec (essentially DID Doc pointing to a <actual issuer's domain>/.well-known/did-configuration.json that contains actual issuer's domain)

tl;dr the proposed mechanism establishes a circular logic between the service provider domain containing actual issuer's identifier and actual issuer listing the service provider's domain as trusted.

some examples..

with option one, metadata hosted under service-provider.com will contain a claim "on_behalf_of": "actual-issuer.com" and under actual-issuer.com/.well-known/authorized_providers the wallet will be able to find a claim "authorized_providers": ["service-provider.com"]

with option 2, metadata hosted under service-provider.com will contain a claim "on_behalf_of": "ey...<JWS>" the payload of which is:

{
"service_provider": "service-provider.com" //I am somewhat worried this is the same as `"credential_issuer"` top-level claim in the issuer metadata.. claim names need to be thought through..
"on_behalf_of": "did:example:<actual-issuer's DID>"
}

under the key to validate this JWS is obtained from "did:example:<actual-issuer's DID>"'s DID Document. the same DID Document contains a service endpoint linkedDomain so that under actual-issuer.com/.well-known/did-configuration.json, the wallet will be able to find "did:example:<actual-issuer's DID>.

[Sakurann]

overall, seems like the direction outlined above seems good, with the following improvements:

• for DID use-cases, define a parameter inspired by “signed_metadata” parameter defined in RFC8414 as @selfissued suggested. JWS in “signed_metadata” will include actual issuer’s DID in iss claim, and domain of the vendor hosting the metadata in sub claim (not sure about other claims like iat, jti…).
• DPoP or MTLS needs to be recommended because metadata is only partially signed and attacker could do MITM by changing the credential endpoint value as suggested by @danielfett
• @peppelinux correctly pointed out that identifying the actual issuer and its domain should be clearly separated from the decision why that issuer is trusted.
• For non-DID use-cases, the URL of the actual issuer can be included as the issuer metadata parameter and appending .well-known path to it will lead to a document hosted under the issuer which contains the vendor’s domain.