Add trust establishment between verifier and issuer

[samuelmr]

Adds a new section "Credential Verifiers Establishing Trust in Credential Issuers"

[samuelmr]

Rendered version

[jogu]

I can see how this would work for (say) SD-JWT (a https url in the iss claim), but how would it work for mdoc? (You can use this spec for mdoc right?)

[peppelinux]

for MDL verification use cases

what about using X509 SAN URIs, including any kind of URI, therefore enabling did methods and URLs?

please note that this is of general interest but out of the scopes of this draft

we could think a impl section about introducing these aspects

[peppelinux]

@jogu see: #45

[jogu]

Ah, so embedding the federation url into the SAN field in the x509 certificate used to sign the mdoc/mdl credential? I guess that might work but I'm not familiar enough with ISO 18013 part 5 to know if that's likely to work well or not.

[TimoGlastra]

please note that this is of general interest but out of the scopes of this draft

Any reason why it is out of scope of this draft? Couldn't we do something like OpenID4VCI and OpenID4VP where we define annexes for specific credential formats? I would like to have it included as part of this draft, it's one of the most important aspects of this specification.

[jogu]

It feels a bit limiting to have federation as the only verifier->issuer trust establishment mechanism? e.g. if an mdl issuer was not part of a federation, that would mean verifiers using federation to establish a relationship with a wallet couldn't then receive mdls that originated from a non-federation supporting mdl issuer?

[peppelinux]

this draft is about using openid federation

mdl issuer using openid4vci can be part of an openid federation

if they do not use openid federation, they would use for sure X.509 PKI and the trust establishment using X.509 certificates is made using certificate chains about using a trusthworthy trust anchor; but this is not in the scopes of this draft.

[jogu]

I get that - I guess what I mean is: should it be broken down into two separate sections that implementors can pick one or both to implement? e.g. I may well want to use openid federation between my wallet and verifiers even if I can't get all my issuers to support federation.

And potentially I might want to use federation between the wallets and issuers even if the verifiers don't all support federation?

[samuelmr]

There are different sections in the draft. 8.6 is about trust between the wallet and the verifier. 8.7 is about trust between the verifier and the issuer.

IMHO, the spec should say how to use OpenID Federation for different purposes. It shouldn't say that all issuers or verifiers must support OpenID Federation. Thus, the implementor is free to build support for 8.6 but not for 8.7.

(Of course, that implementation wouldn't be fully compliant with the spec. If there was an ecosystem that required support for 8.7, the participants in that ecosystem couldn't use software that lacked the support for that.)

[jogu]

Ah okay, it might be good to say somewhere that these are independent sections some of which ecosystems might choose not to use? (That could be a nice issue though.)

[jogu]

I think we need a warning here - the fact that, e.g., iss in a SD-JWT VC is a https url does NOT mean that the issuer supports federation. e.g. SD-JWT VC defines a web based key resolution mechanism that uses https urls.

We should probably include a reference that URLs in the form openid_federation:https://issuer.example.com can be used to unambiguously indicate that federation is used?

[peppelinux]

Suggested change

The [@!OpenID.Federation] specification requires that Entity Identifiers MUST be URLs using the https scheme. In various flavors of digital credentials, the Credential Issuer can be identified in various ways. If the Credential Issuer is identified using a https URL in the digital credential, the Credential Verifier SHOULD use that URL as the Entity Identifier of the Credential Issuer. If the Credential Issuer is identified using other methods that have 1-to-1 mapping to a https URL (e.g., `did:web`, `did:webvh`), the Credential Verifier MAY use that URL as the Entity Identifier of the Credential Issuer. Future versions of this specification may provide other mechanisms to specity the Credential Issuer's Entity Identifier in a digital credential.

The [@!OpenID.Federation] specification requires that Entity Identifiers MUST be URLs using the https scheme. In various flavors of digital Credentials, the Credential Issuer can be identified in various ways. If the Credential Issuer is identified using a https URL in the digital Credential, the Credential Verifier MUST use that URL as the Entity Identifier of the Credential Issuer. If the Credential Issuer is identified using other methods that have 1-to-1 mapping to a URI (e.g., `did:web:`, `did:webvh:`), the Credential Verifier MAY use that URL as the Entity Identifier of the Credential Issuer.

@samuelmr how could an entity be identified using different identifiers, other than https URLs?
I ask since OpenID Federation only uses https URIs.

it might be useful trying to explore the feature proposed in the following issue? #43

[samuelmr]

@peppelinux, see, for example:

• Example 2 in VCDM 2 in which the issuer is identified by "did:example:2g55q912ec3476eba2l9812ecbfe".
• Example 3 where the issuer is "https://university.example/issuers/565049"
• Example 30 where the issuer id is "did:web:credentials.utopia.example"

If you got all those VCs as a verifier, you'd look for https://university.example/issuers/565049/.well-known/openid-federation as the Entity Identifier for the Example 3 and https://credentials.utopia.example/.well-known/openid-federation as the Entity Identifier for the Example 30.

You couldn't get the OpenID Federation Entity Configuration of the issuer of the Example 2 VC since that would require additional discovery mechanisms.

[samuelmr]

I agree with @jogu that there's no guarantee that the Entity Configuration can be found in the Entity Identifier locations of issuers of Example 3 and Example 30.

I would like to see a more explicit reference from a credential to the issuer's Entity Identifier. I made a suggestion in #50, but got feedback (outside GitHub) that new discovery mechanisms should be avoided.

[peppelinux]

removing the requirement to use entity configuration at well-known endpoints is like removing the any other requirement of openid/oauth/connect to use their well-known endpoints

the point is about interop and discovery, see: openid/federation#265

OpenID Federation 1.0 enables interoperability on well known approaches. Other mechanisms will be evaluated and implemented in future version of OpenID Federation (2.0 I suppose).

OpenID Federation Wallet will accomodate any advancements according to future versions of OpenID Federation, without removing its current support to OpenID Federation 1.0

[samuelmr]

I'm not suggesting removing the requirement to use entity configuration at well-known endpoints.

My point in #50 and in the 8.7 section of this proposal is that, as a verifier of a digital credential, you receive a document from a wallet. You don't know which endpoint was used to issue that credential. There is no specification defining how you should find the issuer's well-known endpoint.

Since this is specific to the use case of digital credentials and wallets, the Wallet Architectures specification is the right place to define this behavior.

To repeat myself: the point is not to replace well-known endpoints with an alternative discovery mechanism. The point is to define how the verifier can find the well-known endpoint of the issuer.

[jogu]

I don't understand how the 'SHOULD' here interacts with the MUST in bullet 3? In general I'm not sure about this form of text (i.e. "outlined" and "includes") - we should either refer only to other places that fully normatively define the behaviour, or we should fully normatively define the behaviour in this section (and we should only do the latter in the case where the behaviour isn't described elsewhere already).

[lj-raidiam]

The first SHOULD in this paragraph should a MUST, no? If federation is used for trust establishment in the ecosystem and the issuer is identified with the https scheme, is there a case where a verifier should not use the issuer URL as the Entity Identifier?

When it comes to DIDs, I believe they should be included as alternative identifiers in the issuer's entity statement. If the verifier expects (or knows) that the issuer is part of a federation, they must (or may) establish trust through the federation and verify whether the issuer’s entity statement includes the DID as an alternative identifier.

That said, I’d suggest deferring this change until we open a PR specifically focused on alternative identifiers #43

[jogu]

Ah okay, it might be good to say somewhere that these are independent sections some of which ecosystems might choose not to use? (That could be a nice issue though.)

[jogu]

Rereading I'm concerned about this 'should'. I think it's a 'MUST' if it means "trust" in the generic sense - it's absolutely mandatory that the verifier checks that a credential is correctly signed by an issuer the verifier trusts.

[lj-raidiam]

I agree with @jogu on MUST. In addition the motivation here is primarily authenticity. Also eligibility to issue this type of credential could be added too.

[samuelmr]

In my opinion, this specification should state how a software implementation works. It shouldn't dictate what kind of trust decisions different parties make.

Especially, when a verifier is verifying a credential they have issued themselves, MUST they resolve the OpenID Federation chain? Or if a credential issuer is identified by a DID that they already know?

What if they don't? Is their verification process non-compliant with this spec, even if the software they're using technically supports the capability?

[TimoGlastra]

Not sure we should rely on this 1-1 mapping to a HTTPS url. I think it would make more sense to define how to link a DID to a federation entity (using #43 and a backlink in the DID) in a generic way.