<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>DW has provided most of the answers already. Supplementary ones
below<br>
</p>
<div class="moz-cite-prefix">On 15/04/2022 18:14, George Fletcher
via Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJnLd9+dNax=4ND75SHj9jAjc3m6qdZCPd0v9JetOAYkXfSRNw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">I've been reading through the SIOPv2 spec and
wondering what the work<br>
group thinks is the best way to handle the following use case.<br>
<br>
There is an existing RP that already supports "Sign-in with
Google" and<br>
"Sign-in with Microsoft" via OpenID Connect. The RP want's to
support<br>
Self-Issued OpenID Providers as well.<br>
<br>
This leads to the following questions:<br>
<br>
1. What is the best way to make this option available to the
users of the RP? How does the RP know which wallets the user
might have? </div>
</blockquote>
<p>To give the user full SSI control the RP should not know which
the wallet the user has. The user should be able to choose
whichever wallet best fits their need. The RP may wish to know the
capabilities/functionalities of the user's wallet, but not the
vendor of the wallet software, and this can be done by
certification of the wallet to conform to a particular standard
(e.g. as proposed by the eIDASv2 spec)<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJnLd9+dNax=4ND75SHj9jAjc3m6qdZCPd0v9JetOAYkXfSRNw@mail.gmail.com">
<div dir="ltr">Does the RP need to pre-select only working with a
few wallets and ignore the others?<br>
</div>
</blockquote>
<p>Selecting wallets based on their capabilities should be
supported, but not on their software creator as this leads to
centralisation of control.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJnLd9+dNax=4ND75SHj9jAjc3m6qdZCPd0v9JetOAYkXfSRNw@mail.gmail.com">
<div dir="ltr">2. The RP will need to handle a "registration"
event for the user of the SIOP. Is that an explicit event vs an
implicit one? During registration the RP needs some set of
claims while during normal authentication events, the RP just
needs to have the SIOP solve the authentication request.<br>
3. How does the RP know what verifiable claims the wallet might
be able to provide? As an RP self-asserted claims may not be
sufficient.<br>
4. What if self-asserted claims are sufficient but the SIOP
wallet doesn't support the required requested claim in the
authentication request?</div>
</blockquote>
<p>Wallets should know the schemas of the credentials it already
holds or is capable of holding, so that it can know when they are
well formed or faulty. If the RP is requesting a credential of
unknown type/schema (i.e. an unsupported capability) then this
will presumably be outside of any particular scheme or standard.
Dynamic loading of unknown schemas can lead to security
vulnerabilities and is not recommended.<br>
</p>
<p>kind regards</p>
<p>David<br>
</p>
<blockquote type="cite"
cite="mid:CAJnLd9+dNax=4ND75SHj9jAjc3m6qdZCPd0v9JetOAYkXfSRNw@mail.gmail.com">
<div dir="ltr">
<div>5. The user may have a "merge" required (say RP requested
email address and the one provided in the response matches an
existing identity at the RP). Are there any unique aspects to
"merging" when leveraging "SIOPv2"?<br>
6. If a user loses access to their SIOP, how does the RP
support recovery? Should registration require additional
identification and authentication methods to allow the user to
recover their account in a more traditional way?<br
clear="all">
<div><br>
</div>
<div>Thanks,</div>
<div>George</div>
<input name="virtru-metadata" type="hidden"
value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"persistentProtection":false,"expandedWatermarking":false,"expires":false,"isManaged":false},"attachments":{},"compose-id":"1","compose-window":{"secure":false}}"></div>
</div>
<hr><br>
<br>
<font color="#404040">The information contained in this e-mail is
confidential and/or proprietary to Capital One and/or its
affiliates and may only be used solely in performance of work or
services for Capital One. The information transmitted herewith
is intended only for use by the individual or entity to which it
is addressed. If the reader of this message is not the intended
recipient, you are hereby notified that any review,
retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this
information is strictly prohibited. If you have received this
communication in error, please contact the sender and delete the
material from your computer.</font><br>
<br>
<table width="100%" height="30" cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr>
</tr>
</tbody>
</table>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="https://lists.openid.net/mailman/listinfo/openid-specs-ab">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</body>
</html>