Well-known URI building rules

[danielfett]

VCI currently has the following text:

The Credential Issuer's configuration can be retrieved using the Credential Issuer Identifier.Credential Issuers publishing metadata MUST make a JSON document available at the path formed by inserting the string /.well-known/openid-credential-issuer into the Credential Issuer Identifier between the host component and the path component, if any.

For example, the metadata for the Credential Issuer Identifier https://issuer.example.com/tenant would be retrieved from https://issuer.example.com/.well-known/openid-credential-issuer/tenant. The metadata for the Credential Issuer Identifier https://tenant.issuer.example.com would be retrieved from https://tenant.issuer.example.com/.well-known/openid-credential-issuer.

Practically, https://tenant.issuer.example.com is the same as https://tenant.issuer.example.com/. Following the text in the first paragraph, the metadata for the URL with the trailing slash should reside at https://tenant.issuer.example.com/.well-known/openid-credential-issuer/ (note the trailing slash) and not at https://tenant.issuer.example.com/.well-known/openid-credential-issuer (without the trailing slash).

Since it is very common to omit the trailing slash in URLs without paths, I think that one of the following choices should be made by VCI:

1. allow both forms for cases where the issuer URL does not contain a path component (https://example.com and https://example.com/), or
2. RECOMMEND to use and accept the trail-less well-known URL in such cases.

[christol129]

I have just stumbled over another restriction in
https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-12.2.4-2.1:

credential_issuer: REQUIRED. The Credential Issuer's identifier, as defined in Section 12.2.1. The value MUST be identical to the Credential Issuer's identifier value into which the well-known URI string was inserted to create the URL used to retrieve the metadata. If these values are not identical (when compared using a simple string comparison with no normalization), the data contained in the response MUST NOT be used.

In our case we have:

• credential_issuer = http://demo.pid-provider.bundedruckerei.de
  (from issuer metadata; no trailing slash)
• well_known_url = http://demo.pid-provider.bundedruckerei.de/.well-known/openid-credential-issuer/
  (assembled by the Wallet Unit; with trailing slash)

Using a simple string comparison, these are not identical:

http://demo.pid-provider.bundedruckerei.de
http://demo.pid-provider.bundedruckerei.de/

According to the spec, this means the metadata response MUST NOT be used, which effectively forces us to be extremely strict about trailing slashes when configuring credential_issuer and constructing the well-known URL.

[charsleysa]

The rules were effectively copied from the OAuth Server Metadata RFC8414 spec so the processing and convention is already well known.

The only thing that I see missing that would cover the trailing slash issue is the following text from section 3.1 of RFC8414:

If the issuer identifier value contains a path component, any
terminating "/" MUST be removed before inserting "/.well-known/" and
the well-known URI suffix between the host component and the path
component.

[christol129]

The rules were effectively copied from the OAuth Server Metadata RFC8414 spec so the processing and convention is already well known.

The only thing that I see missing that would cover the trailing slash issue is the following text from section 3.1 of RFC8414:

If the issuer identifier value contains a path component, any
terminating "/" MUST be removed before inserting "/.well-known/" and
the well-known URI suffix between the host component and the path
component.

This sounds reasonable to me, and it keeps the authorization server and issuer metadata consistent.