[OIDC Federation] Trust Patterns - Wallets

[Alen Horvat]

Hi.

Based on the discussion https://github.com/openid/OpenID4VCI/issues/71#issuecomment-1721676675 I’m opening this ticket to discuss and understand better the OIDC Fed. patterns.

My understanding is the following:

• OIDC Fed. defines creation and issuance of entity statements and construction of trust chains (trust chain == a sequence of entity statements)

In the context of digital wallet instances, the digital wallet has access to private/public key pairs and it also ships with wallet configuration (that usually needs to be presented to the issuer/verifier).

Since the trust chain can be put in any JWT/JWS header (currently via protected trust_chain claim), I identified the two patterns below, and I’d like to see whether my understanding of the possible usage of trust chains and entity statements is correct.

a) Wallet provider issues entity statement + trust chain to the wallet instance; wallet instance is the leaf. The wallet instance entity statement contains the signed wallet configuration and wallet’s key(s) – ideally, there should be 1 Entity Statement/key. Of course, the (mobile) wallet instance won’t have any public endpoint. In this case, whenever required, the wallet can simply sign a request/response and put the trust_chain in the header. From the signature itself, the issuer/verifier can determine everything it needs to trust the wallet or not. (when this trust is established, whether the issuer requests additional info, … is not relevant to this discussion)

b) The wallet provider issues a credential to the wallet instance and the wallet provider is the last one in the trust chain.

---

b) is something that Italy implemented, if I understood correctly;

My question is whether a) is a valid pattern? (I took the example of a wallet instance, but can be applied in other contexts)

‌

[Giuseppe De Marco]

Hey Alan, thank you for this issue, my answer below

a) the wallet instance is not a federation entity, then it doesn’t have an entity configuration since it shall not publish a .well-known/openid-federation. This implies that the wallet instance cannot have a trust chain related to itself. The wallet provider is a federation entity and it issues a wallet instance attestation to its wallet instances, within the signed wallet instance attestation there are all the information required to establish the trust to its issuer, then the trust_chain within the JWS headers

b) yes, the wallet provider’s entity configuration is the first entry within the trust _chain where the last one is the statement issued by Trust Anchor

I would not go for A in the current implementation even if there may be implementation that wants wallet instances as federation entities and these then have to publish the .well-known/openid-federation endpoint. This is technically possible but I discourage this because the wallet instance are personal devices and not organizational entities deployed as public internet services

‌

[Michael Jones]

Marked "new" on the 21-Sep-23 working group call.

[Michael Jones]

We discussed this on the 22-Sep-23 Federation Editors' call. Giuseppe is in a conversation with Alen about it.

[Giuseppe De Marco]

Me and Alen agreed that Federation can be used in different ways based on what is considered an organizational entity and what is not.

This implies that a wallet instance attestation should not be issued in the form of an Entity Statement because the wallet instance is not an organizational entity. The wallet instance is a personal device that obtains a verifiable attestation provided by its wallet provider.

To date the implementation of federation for the wallet ecosystem assumes only the option b) discussed in this thread and according to this implementation profile, other implementations may born within specific implementation profiles.

‌