[OpenID-Specs-eKYC-IDA] Connecting OIDC4IDA and Wallet functionality

[Kai Lehmann]

Hi David,

thanks for your answer. I think I have to dig deeper into the SIOP/VP protocol family. Do I understand correctly that the SIOP/OID4VP protocols are essentially incompatible with the OIDC4IDA protocol? Our aim was that the RP uses the same protocol when communicating with OPs and the Wallet when requesting verified claims. In fact, the idea was that there is a broker in between RP and OPs/Wallet which can delegate the request to the original OP or the Wallet depending on whether the OP can fulfil the request and/or whether the Wallet has the requested data available already.

Best regards,
Kai

From: Openid-specs-ekyc-ida <openid-specs-ekyc-ida-bounces at lists.openid.net> on behalf of David Chadwick via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net>
Organisation: Verifiable Credentials Ltd
Reply to: OpenID eKYC Identity Assurance Working Group <openid-specs-ekyc-ida at lists.openid.net>
Date: Friday, 18. November 2022 at 14:37
To: "openid-specs-ekyc-ida at lists.openid.net" <openid-specs-ekyc-ida at lists.openid.net>
Cc: David Chadwick <d.w.chadwick at verifiablecredentials.info>
Subject: Re: [OpenID-Specs-eKYC-IDA] Connecting OIDC4IDA and Wallet functionality


Hi Kai

the way that the OID4VCs protocols are designed to work is that the wallet first acts as an RP and collects together the verified data (as verifiable credentials) perhaps long before they are needed by any "real RP", using the OID4VCI protocol. The wallet user may collect verified data from multiple OPs in their wallet.

Then when the user approaches the RP, the RP uses the OID4VP protocol (along with optionally the SIOPv2 protocol) to request a subset of this verified data from the wallet.  (SIOPv2 is used if an id_token is required by the RP).

So in this model the RP will need to support both the OID4VP protocol (and optionally the SIOPv2 protocol) as well as the OIDC4IDA protocol

Kind regards

David
On 18/11/2022 11:40, Kai Lehmann via Openid-specs-ekyc-ida wrote:
Hi all,

sorry in advance for the long mail ….

I would like to discuss the following use case which combines identity assurance and wallet functionality:

A relying party would like to have verified claims about the End-User.  The OP responsible for that End-User may or may not be able to provide the verified claims with the restrictions requested by the RP (specific trust framework, type of evidence). If the OP is able to provide the verified data, it can simply return the data to the RP via OIDC4IDA protocol. If it is unable to provide the verified claims as is, the OP may trigger an ad-hoc ident verification process of the End-User by incorporating a 3rd party identification service provider.

instead of (or besides) storing the verified data at the OP for later use/requests from this or other RPs, the OP offers the End-User to store the verified data in a Wallet application. In fact, the Wallet application may not only able to store identities, but also to provide identification services and store the verified identity within the Wallet. So the OP just triggers the whole identification process with the Wallet application and the verified data is then returned by the Wallet – preferably using the OIDC4IDA protocol to have a common interface used by the RP.

Part of the verified claim data is also the email address. The identification service is unable to verify the email address or we may not want to throw another email verification process at the End-User, because the OP already knows the email address and verified it. The OP may possess additional verified claims which we would like to store with the identity inside of the Wallet. The question now is, what is the protocol to be used to provide the Wallet/Identification service provider with already verified data (along with the necessary evidence/process information) which should be stored in the Wallet.

The Wallet/Identification service provider can be seen as a 3rd party OP which essentially provides the verified claims in the end. So the idea is to at least provide the data already verified by the original OP and then do another request to the Wallet as OP and provide the data as identity assertion. We thought of simply providing the ID Token containing the verified data to the Wallet OP with the authorize request would fit nicely. The parameter id_token_hint may not fit here as id_token_hint is supposed to contain the ID Token issued by the same OP and not another one. So a different parameter may be more appropriate. Whatever is transferred from the original OP to the Wallet (directly or indirectly) needs to be signed of course so that the Wallet can verify the authenticity and integrity.

There are drafts regarding Verifiable Presentation (https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) and Verifiable Credentials Issuance (https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) – the latter is not referenced on the OIDC specs overview page, but can be found with Google by the way – which seem to cater to the use case I described. However the presentation format is based on DID which has some similarities with OIDC4IDA verified claims, but has significant differences.

So are the mentioned drafts the ones which should be used in this scenario? How can we make it easier for RPs that they do not need to understand both protocols?

(I will probably need to address the Connect WG as well as they have been working on the mentioned drafts, but some authors are also involved in this WG.)

Thanks,
Kai



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20221121/7c90b40e/attachment.html>