<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Kai</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.</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).<br>
</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</p>
<p>Kind regards</p>
<p>David<br>
</p>
<div class="moz-cite-prefix">On 18/11/2022 11:40, Kai Lehmann via
Openid-specs-ekyc-ida wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4D584A7D-4A4E-4645-84A3-E790D43D2F13@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 all,<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">sorry in advance for the long mail ….<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">I would like to discuss the following use case
which combines identity assurance and wallet functionality:<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">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.<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">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.<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">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.<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">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.<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">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.<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">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?<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">(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.)<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">Thanks,<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>
<p class="MsoNormal"><span 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" lang="EN-GB">From:
</span></b><span style="font-size:12.0pt;color:black"
lang="EN-GB">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 Mark Haine 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>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>Wednesday, 16. November 2022 at 15:34<br>
<b>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>Cc: </b>Mark Haine <a class="moz-txt-link-rfc2396E" href="mailto:mark@considrd.consulting"><mark@considrd.consulting></a><br>
<b>Subject: </b>[OpenID-Specs-eKYC-IDA] Proposed eKYC and
IDA WG Agenda for 09-16-2022<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
lang="EN-GB">Hi
All,<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB"> <o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
lang="EN-GB">Brief
review of
external Orgs
& Events<o:p></o:p></span></p>
</div>
<div>
<p
class="MsoNormal"><span
lang="EN-GB">
Future
Identity
Festival
London<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB">
IIW<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB">
Identiverse
call for
papers<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB">Main
Agenda Items<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB">
Shall we move
to final
review? <o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB"> <o:p></o:p></span></p>
</div>
<div>
<p
class="MsoNormal"><span
lang="EN-GB">Review
PRs<o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">Identity
Assurance<o:p></o:p></span></p>
</div>
<div>
<p
class="MsoNormal"><span
lang="EN-GB">
PR#146 <a
href="https://bitbucket.org/openid/ekyc-ida/pull-requests/146"
moz-do-not-send="true">
Updates to
Authority
draft</a> -
Adrian<o:p></o:p></span></p>
<p
style="margin:0cm"><span
lang="EN-GB">Review
Issues<o:p></o:p></span></p>
<p
style="margin:0cm"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">Identity
Assurance<o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">
New<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">
Close<o:p></o:p></span></p>
<p
style="margin:0cm"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">
Review<o:p></o:p></span></p>
<p
style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:72.0pt;text-indent:36.0pt"><span
lang="EN-GB">Issue
<a
href="https://bitbucket.org/openid/ekyc-ida/issues/1331/possible-type-confusion-with-distributed"
title="#1331:
possible type
confusion with
distributed/aggregated claims" moz-do-not-send="true">
#1331:
possible type
confusion with
distributed/aggregated claims</a> – Joseph<o:p></o:p></span></p>
<p
style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:72.0pt;text-indent:36.0pt"><span
lang="EN-GB">Issue
<a
href="https://bitbucket.org/openid/ekyc-ida/issues/1330/suggest-that-there-be-a-default-for"
title="#1330:
Suggest that
there be a
default for
"attachments_supported""
moz-do-not-send="true">
#1330: Suggest
that there be
a default for
"attachments_supported"</a> – Mark<o:p></o:p></span></p>
<p
style="margin:0cm"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">Advanced
Syntax for
Claims<o:p></o:p></span></p>
<p
style="margin:0cm"><span
lang="EN-GB">
Update from
Daniel and
Mark on SAO
syntax
thinking<o:p></o:p></span></p>
<p
style="margin:0cm"><span
lang="EN-GB"><o:p> </o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">
New<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB">
<o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">
Close<o:p></o:p></span></p>
<p
style="margin:0cm"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">
Review<o:p></o:p></span></p>
<p
class="MsoNormal"
style="margin-left:72.0pt;text-indent:36.0pt"><span lang="EN-GB">Issue
<a
href="https://bitbucket.org/openid/ekyc-ida/issues/1327/age-verification-examples-in-the-advance"
title="#1327:
Age
verification
examples in
the Advance
Syntax Draft"
moz-do-not-send="true">
#1327: Age
verification
examples in
the Advance
Syntax Draft</a>
- Nat<o:p></o:p></span></p>
<p
class="MsoNormal"
style="margin-left:72.0pt;text-indent:36.0pt"><span lang="EN-GB">Issue
<a
href="https://bitbucket.org/openid/ekyc-ida/issues/1276/sao-output-claim-set-varies-depending-on"
title="#1276:
[SAO] Output
claim set
varies
depending on
evaluation
order"
moz-do-not-send="true">
#1276: [SAO]
Output claim
set varies
depending on
evaluation
order</a> –
Daniel<o:p></o:p></span></p>
<p
class="MsoNormal"
style="margin-left:72.0pt;text-indent:36.0pt"><span lang="EN-GB">Issue
<a
href="https://bitbucket.org/openid/ekyc-ida/issues/1320/claim-controls"
title="#1320:
Claim
Controls"
moz-do-not-send="true">
#1320: Claim
Controls</a> -
Taka<o:p></o:p></span></p>
<p
class="MsoNormal"
style="margin-left:72.0pt;text-indent:36.0pt"><span lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">Authority<o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">
New<o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">
Close<o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm;text-indent:36.0pt"><span
lang="EN-GB">
Review<o:p></o:p></span></p>
<p
class="MsoNormal"
style="margin-left:72.0pt;text-indent:36.0pt"><span lang="EN-GB">Issue
<a
href="https://bitbucket.org/openid/ekyc-ida/issues/1236/act-as-a-staff-but-assert-directors"
title="#1236:
Act as a
staff, but
assert
director's
verified
claims"
moz-do-not-send="true">
#1236: Act as
a staff, but
assert
director's
verified
claims</a> –
Mark<o:p></o:p></span></p>
<p
class="MsoNormal"
style="margin-left:72.0pt;text-indent:36.0pt"><span lang="EN-GB">Issue
<a
href="https://bitbucket.org/openid/ekyc-ida/issues/1258/represent-legal-entity-beneficial-owner"
title="#1258:
Represent
legal entity
beneficial
owner"
moz-do-not-send="true">
#1258:
Represent
legal entity
beneficial
owner</a>
Mark<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB">
Other
non-draft
related topics<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB">
Additional
claims and
structured
claims<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB">
Pending
Verification<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB">AOB<o:p></o:p></span></p>
<p
class="MsoNormal"><span
lang="EN-GB"> <o:p></o:p></span></p>
<p
style="margin:0cm"><b><span
lang="EN-GB"> Mark</span></b><span
lang="EN-GB"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>