issuer identifier - always HTTPS URL..?

[Sakurann]

Which HTTPS URL does the issuer use when x.509 is used? SAN? if we mandate issuer to do both x.509 and SAN, does that mean issuers must make sure /JWT-issuer is hosted under SAN? Isn’t that pretty limiting? (I am not necessarily opposed to “iss is always a URL, just trying to understand the implications)

[tlodderstedt]

According to the feedback we got so far on the concept, I think SNA is the way to go.

I see value in the proposal @tplooker made to always use the same kind of iss value. It is especially beneficial if the credential has both the x.509 cert chain and support for web based key resolution, since the verifier can choose what data to use for validation.

If the credential only has x.509, it doesn't matter in the end what identifier we use as long as the leaf cert binds that identifier to the public key of the issuer. So using the HTTPS URL doesn't hurt at least and might be inline with the way domain validated certs (and cWACs? @paulbastian) work.

Even HTTPS URL with paths should work. I checked https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6 and did not find an indication that this would not be possible. I mention it because as far as I remember someone stated that a SNA would only contain a URL with FQN but no path.

Isn’t that pretty limiting?

In my opinion, the issuer can freely choose the URL so it should not become a limitation. However, I also think we need implementors' feedback.

[paulbastian]

I agree using iss field for x509 as well. It has the advantage of having a common identifier for both mechanisms. EV and QWAC work the same way

[peppelinux]

If the goal of the x5c is the key attestation, this works fine.

If instead policies and additional information like metadata are required, x5c simply doesn't work unless it would be "inflated" with custom elements for carrying metadata and policies and grants. That from what can be said about x509, inflating it so much would be like making an 80-year-old man do bodybuilding!

I suggest the inclusion of OIDC Federation Trust chain in this profile, that's both web attested key and chain of verifiable statements issued by more than a single party.

the key question is: what defines the level high? key attestations (as oidc core did for years) or a high level would bring also grants/policies, metadata and all the interop schema as high verifiable and assured?

Since every issued VC or any kind of attestation should not be repudiable in the future, that's something pertaining the assurance level I think

[tlodderstedt]

@peppelinux This issue is about the question what the identifier of an issuer is in a VC. Since we are leaning towards using a HTTPS URL, that would work for federation, too.

[peppelinux]

I agreed, since federation only uses HTTPs but from Draft 29 there's the trust_chain JWS header claim that allows metadata, keys and policies attestation even in offline flows

an https alone is not attestable in offline flows and x509 doesn't have metadata, policies and trust marks/additional-VCs in it related to the issuer

federation trust_chain has

[tlodderstedt]

@peppelinux I have to admit I don't fully understand your arguments. This issue is about the value of the iss value in the credential. A HTTPS URL works fine with OpenID Federation as well, right? So I don't see a problem.

[peppelinux]

yes, I went quite out of the border

The question is there any interest to have different kind of issuer identifiers?

I'm in favor of HTTP URLs, even if there may be some cases where a did resolution methods resolve to HTTPs URL as well, as discussed in the issue below: https://github.com/vcstuff/draft-terbu-sd-jwt-vc/issues/41#issuecomment-1546743042

Anyway, if there are milestone in this project this question doesn' seem a priority since that this profile can satisfy its scope using HTTPs URL

so accept my excuse for the noise, it was just for sharing

[Sakurann]

I think what I would like to see is a clear validation logic, something like:

• when only x509 is used (kid JOSE header is not present), iss is a SAN. when verifying, must be an absolute match btw the value in iss and x509 leaf cert.
• when only web PKI based approach is used (x5c JOSE header is not present), iss is a URL where the key is hosted, it can include path and subdomain.
• when both x509 and web PKI based are used (both x5c and kid header is present), iss is a URL where the key is hosted, can include path and subdomain. Verifier must strip down path and subdomain and use only the domain when comparing with the SAN in x509 cert.

not sure it is clean to use header parameters as a switch, but that's how the verifier will determine which mechanism is used, right?

don't know if it is a limitation, but essentially, Web PKI based approach must host the keys at the domain that is also in the x509 cert.