<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>If you have a broker in between the RP and the wallet or OP then
I see no reason why the broker cannot talk the correct (albeit
slightly different) protocol to both of these. The RP then only
needs to speak one protocol to the broker</p>
<p>Kind regards</p>
<p>David<br>
</p>
<div class="moz-cite-prefix">On 21/11/2022 07:27, Kai Lehmann wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01F03F29-533C-40F3-A960-CAA18C85718B@1und1.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@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;}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;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="DE">Hi David,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="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 style="mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">Kai<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="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
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ekyc-ida-bounces@lists.openid.net"><openid-specs-ekyc-ida-bounces@lists.openid.net></a> on
behalf of David Chadwick via Openid-specs-ekyc-ida
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ekyc-ida@lists.openid.net"><openid-specs-ekyc-ida@lists.openid.net></a><br>
<b>Organisation: </b>Verifiable Credentials Ltd<br>
<b>Reply to: </b>OpenID eKYC Identity Assurance Working
Group <a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ekyc-ida@lists.openid.net"><openid-specs-ekyc-ida@lists.openid.net></a><br>
<b>Date: </b>Friday, 18. November 2022 at 14:37<br>
<b>To: </b><a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ekyc-ida@lists.openid.net">"openid-specs-ekyc-ida@lists.openid.net"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ekyc-ida@lists.openid.net"><openid-specs-ekyc-ida@lists.openid.net></a><br>
<b>Cc: </b>David Chadwick
<a class="moz-txt-link-rfc2396E" href="mailto:d.w.chadwick@verifiablecredentials.info"><d.w.chadwick@verifiablecredentials.info></a><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 style="mso-fareast-language:EN-US"
lang="DE">Hi all,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="DE"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">sorry in advance for the long mail ….</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="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 style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="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 style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="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 style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="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 style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="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 style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">There are drafts regarding Verifiable
Presentation (<a
href="https://openid.net/specs/openid-4-verifiable-presentations-1_0.html"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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 style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="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 style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="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 style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">Kai</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</body>
</html>