<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="en-DE" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="DE" style="mso-fareast-language:EN-US">Hi David,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="DE" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Kai<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Openid-specs-ekyc-ida <openid-specs-ekyc-ida-bounces@lists.openid.net> on behalf of David Chadwick via Openid-specs-ekyc-ida <openid-specs-ekyc-ida@lists.openid.net><br>
<b>Organisation: </b>Verifiable Credentials Ltd<br>
<b>Reply to: </b>OpenID eKYC Identity Assurance Working Group <openid-specs-ekyc-ida@lists.openid.net><br>
<b>Date: </b>Friday, 18. November 2022 at 14:37<br>
<b>To: </b>"openid-specs-ekyc-ida@lists.openid.net" <openid-specs-ekyc-ida@lists.openid.net><br>
<b>Cc: </b>David Chadwick <d.w.chadwick@verifiablecredentials.info><br>
<b>Subject: </b>Re: [OpenID-Specs-eKYC-IDA] Connecting OIDC4IDA and Wallet functionality<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p>Hi Kai<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>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).<o:p></o:p></p>
<p>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<o:p></o:p></p>
<p>Kind regards<o:p></o:p></p>
<p>David<o:p></o:p></p>
<div>
<p class="MsoNormal">On 18/11/2022 11:40, Kai Lehmann via Openid-specs-ekyc-ida wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="DE" style="mso-fareast-language:EN-US">Hi all,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="DE" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">sorry in advance for the long mail ….</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I would like to discuss the following use case which combines identity assurance and wallet functionality:</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">The Wallet/Identification service provider can be seen as a 3<sup>rd</sup> 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.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">There are drafts regarding Verifiable Presentation (<a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0.html">https://openid.net/specs/openid-4-verifiable-presentations-1_0.html</a>)
and Verifiable Credentials Issuance (<a href="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html">https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html</a>) – 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.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">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?</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">(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.)</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Kai</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
</blockquote>
</div>
</body>
</html>