OID4VPs - need to specify the trust model

[David W Chadwick]

We should specify the trust model for wallets trusting verifiers and add this to the specification. Here is a strawman proposal for this

TRUST MODEL FOR WALLETS PRESENTING CREDENTIALS

The wallet/holder cannot trust the verifier without either some pre-existing knowledge of the verifier or a trust infrastructure to inform it. This specification provides a mechanism for the latter. The consequences of this trust model is that nothing asserted by the verifier can be trusted, such as its client_id or metadata.

1. The wallet/holder is a member of one or more trust domains, and knows how to contact it to ask if a verifier is trusted
2. Trusted verifiers must have their client_id recorded in one or more trust domains.
3. Wallet/holders can determine if the asserted client_id is trusted by asking its trust domain
4. The location of the verifier’s metadata must either be recorded in the trust domain and returned to the wallet/holder along with the affirmation of trust in the client_id, or there must be an algorithmic way for the wallet to determine the location of the verifier’s metadata based on its trusted client_id

‌

Note. We might also want to write the trust model for verifiers trusting issuers and verifiers trusting wallets.

[Kristina Yasuda]

discussed at the Pacific Connect call

[Kristina Yasuda]

summary of what we discussed and understood during the Pacific Connect call:

David's proposal is "not to use the value passed in the client_id parameter, but to pass multiple client_id values each one for the separate trust method, so that the wallet can pick one that it supports."

guess example would look something like:

"trust_methods": [
 { 
  "client_id": "did:example:123", 
  "method": "did" 
 }, 
 {
  "client_id": "https://client.example.com", 
  "method": "openid_federation" 
 }
],
"client_id": "qwerasdaf",
"redirect_uri": "https://client.example.com/cb"

the problem that is being addressed is an open world model, where any wallet can talk to any verifier and since they do not know each other’s "trust mechanism", they can't talk unless they can find at least one mutual trust mechanism.

one more solution discussed was to have a negotiation step before authorization request - response.

[Kristina Yasuda]

now chair hat off, I strongly believe we should not go with the proposed solution.

First, the WG never agreed on solving the open world model. to do that there needs to be a negotiation before sending an authorization request - ISO mDL does it, because in their use-case there is a need for a guaranteed interoperability. but in OpenID4VP, that is not the goal. even if we guaranteed that both wallet and the verifier speak at least one same trust framework they won’t be interoperable unless they support the same credential format, cryptosuites, etc. and if they support the same credential format, they would know in advance trust mechanism supported by both. So this is a slippery slope.

Second, I can only see red flag with passing more than one value that can be used as a client_id, so that the wallet can choose from. that is absolutely against the security model of OAuth.

[Kristina Yasuda]

Yes, there are multiple mechanisms to obtain metadata and establish trust level, and PR #427 makes it simpler and easier for the verifier to communicate to the wallet which one is used. if the verifier knows the wallets authorization endpoint to send the authorization request, it should be able to discover wallet’s metadata (whether it is static or not), so no need to send multiple client metadata discovery options in one authorization request.

Besides, now verifier has to maintain the same metadata information in multiple places…

[David W Chadwick]

Kristina thank you for summarising approximately what I am proposing for another issue (#1551) and PR(#427). Your comments above really belong there. The current issue is saying that we need a trust model documented in the standard regardless of the protocol parameters. So can we please keep our issues separate and just discuss in this issue about whether we need to document a trust model or not. Thanks.

[David W Chadwick]

And here is a straw man for trust in the wallet.

TRUST MODEL FOR VERIFIERS RECEIVING CREDENTIALS

The client/verifier cannot trust claims made by the wallet/holder since the latter is operating under the control of the user. This specification provides a mechanism for the former to trust the claims of the latter.

1. user claims may be asserted and cryptographically protected by a trusted third party, the credential issuer, so that the verifier can ascertain the technical integrity of the claims by validating the cryptographic proof on the claims provided by the issuer.
2. verification that the claims are coming from the same wallet/holder that the issuer issued them to, may be provided by the cryptographically protected claims containing a public key of the holder, and the holder digitally signing the verifiable presentation that is returned to the authorisation request.

Note that currently it is not possible to verify that it is the same human user that is using the wallet during both the issuing and presentation phases without relying on the wallet to ensure this binding. This might be provided by the verifier requiring assertions from the wallet software provider and from the device hardware provider.

‌

[Torsten Lodderstedt]

I agree with the proposed direction.

Trusted verifiers must have their client_id recorded in one or more trust domains.

I don’t think this will work. In my experience, the client id is determined by the trust method and domain. Suggest: “The client id must have a meaning and identify the verifier in the context of a certain trust method.“

The location of the verifier’s metadata must either be recorded in the trust domain and returned to the wallet/holder along with the affirmation of trust in the client_id, or there must be an algorithmic way for the wallet to determine the location of the verifier’s metadata based on its trusted client_id

This seems to be to narrow as there are mechanisms where the metadata come along with the request (e.g. as a x.509 cert or any other 3rd party issued assertion). The trust method determines the way the metadata is obtained. The trust method may also allow the verifier to provide self asserted metadata. For example, if the verifier signs with a trust worthy key, it can determine the redirect uri on its own. Same holds true for key material used for other purposes (such as response signing and/or encryption).

[David W Chadwick]

In my experience, the client id is determined by the trust method and domain.

I agree. I don’t think my statement disagreed with this. It said this client id must be recorded in the trust domain. It did not say WHO determined it.

where the metadata come along with the request (e.g. as a x.509 cert

I also agree with this. I think that an X.509 PKC signed by a TTP that contains the client’s metadata also conforms to my statement “the verifier’s metadata must either be recorded in the trust domain and returned to the wallet/holder along with the affirmation of trust in the client_id” since the X.509 PKC is the affirmation of trust in the client_id and its metadata and is signed by the TTP.

[David W Chadwick]

if the verifier signs with a trust worthy key, it can determine the redirect uri on its own

I also agree with this. I think this comes under “an algorithmic way for the wallet to determine the location of the verifier’s metadata”

[Kristina Yasuda]

I think this is now also covered in depth with OpenID 4 VC Security Analysis.

[David W Chadwick]

Can you point me to this specific text please

[Kristina Yasuda]

openid / connect / Pull Request #468: First draft of OpenID 4 VC Security Analysis — Bitbucket

‌

[Kristina Yasuda]

this has been resolved by the introduction of client_id_scheme