Trust model for wallet

[David W Chadwick]

Can we add some text to OIDC4CI to say what the Issuer’s trust model is for the wallet i.e. is the wallet untrusted and can be provided by any software vendor, or will the issuer only issue credentials to trusted wallets from certified software issuers.

[Tom Jones]

This is probably impossible as different mobile creds have different models. I try here to explain.

1. The mDL is biometrically bound to the user, so the requirement to trust the wallet is small.
2. The VC is bound to a synthetic Identifier, so the requirement to bind the VP to the user is high.

This difference is likely to limit the usefulness of the VC or to require an aggregation of VCs to satisfy most use cases.

‌

[Tobias Looker]

I think the fact that OIDC (via OAuth) sets up the model where by the wallet provider has its own identity, primarily communicated in the protocol via the client_id creates a flexible basis for a variety of different trust models to thrive. I can see some ecosystems for high assurance credentials opting to allow only certain wallets (e.g clients) perform certain issuance flows (because they must meet some level of compliance), through to other ecosystems where any wallet is allowed and things like client registration is used to allow wallets to register just in time to claim a particular credential.

[Tobias Looker]

In short I dont think the trust model is substantively different than conventional OIDC OAuth and hence no further elaboration is really required.

[Jeremie Miller]

In short I dont think the trust model is substantively different than conventional OIDC OAuth and hence no further elaboration is really required.

Agreed.

[Tom Jones]

In OIDC the relying party determine a priori which IdPs to enable. In SIOP the user determines which wallet to use. Those trust models could not be more different.

[David W Chadwick]

@Tom. In OIDC the user chooses which browser to use to mediate between the IdP and RP. In SIOP the user chooses which wallet to use. In both cases the tokens are signed by the IdP and validated by the RP. So I too don't think the trust model is substantially different to conventional OIDC

[Tobias Looker]

In OIDC the relying party determine a priori which IdPs to enable

This selection is often less about trust and more about RP’s selecting which IDPs they want to support to be-able to provide easy login options for their End-Users. For example as an RP I might add google, linkedin and facebook as login options to my site, not because they are the IDPs I most trust, but instead because they collectively offer easy login options across my user-base. What often stops RP’s from adding more is also not about trust but essentially the NASCAR problem.

‌

[Tom Jones]

Has anyone taken the time to write out a trust model for Relying Parties for self-issued identifiers? It would be a great idea to ask some of them if they agreed with the model and would deploy the feature.

[Kristina Yasuda]

let’s not confuse trust model of OIDC4VCI and SIOPv2 - in the former wallet is the RP and, in the latter, wallet is the OP, which makes a difference.

This issue is about OIDC4VCI. I agree with Tobias that trust model of OIDC4VCI is the same as in OIDC/OAuth and it is out of scope to enumerate Issuer’s possible various trust models.

Having said that, clarifying how Issuer can check whether they trust a certain wallet with a requested credential might be beneficial? such as information on the secure area, like ISO mDL issuance draft does. And maybe the answer is to use OIDC Registration metadata, or maybe it is worth defining a structure like a registration parameter in SIOP request...

[Jeremie Miller]

And maybe the answer is to use OIDC Registration metadata, or maybe it is worth defining a structure like a registration parameter in SIOP request

My thought was that the new proof value would be used for this?

[Tom Jones]

@Kristina: Do you really mean to say that a wallet would say something different to a issuer vs a verifier?

[Kristina Yasuda]

@jeremie, yes. related iIssue #1461.

@Tom, I am saying that wallet is RP to the Issuer and OP to the verifier

[Tom Jones]

@K - well that doesn’t really answer my question.

But i will say that that is the craziest use of terminology i have heard in at least a week,

Shouldn’t the terminology make at least some sense? The wallet is an RP? No way!

[David W Chadwick]

@Tom. In the VC data model, the issuer, holder, and verifier are three roles. Any piece of software can act in any of these three roles. So a user wallet may act as issuer, holder and verifier at different times and in different protocol flows. So the wallet can indeed be an RP in a particular flow if it is verifying a credential sent to it.

@Kristina. Whilst the trust model is broadly similar to the OAuth one, when we are discussing the use of FIDO between the wallet and the issuer, and the user is providing consent to the wallet which it relays to the issuer, then the issuer must trust that the wallet has asked for and obtained consent from the user. I have made this point in PR#137. Furthermore the issuer has already authorised the wallet to establish a FIDO connection (with Google Android authenticators) so the issuer must trust the wallet to some extent in order to authorise this connection.

[Kristina Yasuda]

pending close. this has been addressed in this section https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#section-11.1

[David W Chadwick]

Thankyou!!