<div dir="ltr">Hi Tony,<div><br></div><div>Are you able to elaborate on this statement?</div><div><br></div><div>> <span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px">ZKP work has been done with JWTs too</span></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Thanks,<br><table width="auto" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium;border:0px"><tbody><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td width="125" valign="top"><a href="https://mattr.global" style="border:none;color:rgb(15,173,225)" target="_blank"><img src="https://mattr.global/assets/images/MattrLogo.png" alt="Mattr website" width="125" height="125" style="height:auto"></a></td><td width="16"> </td><td width="159" valign="top" style="color:rgb(51,49,50);font-size:12px"><table cellpadding="0" cellspacing="0" border="0" style="border:0px"><tbody><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td><strong style="font-size:12px">Tobias Looker</strong><br></td></tr><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td style="line-height:16px">Mattr</td></tr><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td style="line-height:16px;padding-top:12px">+64 (0) 27 378 0461<br><a href="mailto:tobias.looker@mattr.global" style="border:none;color:rgb(51,49,50)" target="_blank">tobias.looker@mattr.global</a></td></tr><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td style="font-size:12px;padding-top:12px"><table cellpadding="0" cellspacing="0" border="0" style="border:0px"><tbody><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td width="40"><a href="https://mattr.global" style="border:none;color:rgb(51,49,50);margin-right:12px" target="_blank"><img src="https://mattr.global/assets/images/website.png" alt="Mattr website" width="24" style="border:0px;height:40px;width:24px"></a></td><td width="40"><a href="https://www.linkedin.com/company/mattrglobal" style="border:none;color:rgb(51,49,50);margin-right:12px" target="_blank"><img src="https://mattr.global/assets/images/linkedin.png" alt="Mattr on LinkedIn" width="24" style="border:0px;height:40px;width:24px"></a></td><td width="40"><a href="https://twitter.com/mattrglobal" style="border:none;color:rgb(51,49,50);margin-right:12px" target="_blank"><img src="https://mattr.global/assets/images/twitter.png" alt="Mattr on Twitter" width="24" style="border:0px;height:40px;width:24px"></a></td><td width="40"><a href="https://github.com/mattrglobal" style="border:none;color:rgb(51,49,50);margin-right:12px" target="_blank"><img src="https://mattr.global/assets/images/github.png" alt="Mattr on Github" width="24" style="border:0px;height:40px;width:24px"></a></td></tr></tbody></table></td></tr></tbody></table></td></tr></tbody></table><br style="color:rgb(0,0,0);font-family:Times;font-size:medium"><small style="color:rgb(118,118,118);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:8px;line-height:14px">This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.</small><br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 8, 2021 at 6:52 PM Kristina Yasuda via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Notes are also <a href="https://bitbucket.org/openid/connect/wiki/2021-03-02" title="https://bitbucket.org/openid/connect/wiki/2021-03-02" target="_blank">here</a> (Connect WG Bitbucket Wiki).</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Albert Solana
<div>Justin Richer</div>
<div>Vittorio Bertocci</div>
<div>Anthony Nadalin</div>
<div>Tom Jones</div>
<div>David Waite</div>
<div>Oliver Terbu</div>
<div>Tim Cappali</div>
<div>Jeremie Miller</div>
<div>Adam Lemmon</div>
<div>Kaliya Young</div>
<div>Edmund Jay</div>
<div>Markus Sabadello</div>
Kristina Yasuda<br>
</div>
<div id="gmail-m_-90882616163421252divRplyFwdMsg" dir="ltr">
<ul>
<li><span> <span style="font-size:11pt">IPR Agreement</span></span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US"><span style="font-size:11pt">As the SIOP special calls are part the AB/Connect Working Group, anyone wishing to participate and contribute need to submit a contribution agreement:
</span><a href="https://openid.net/intellectual-property/" target="_blank"><span style="font-size:11pt">https://openid.net/intellectual-property/</span></a><span style="font-size:11pt">. The agreement signed between DIF and OIDF doesn't extend to their member's IPR. I
again apologize for the confusion this question may have caused during the call.</span></li></ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US"><span style="font-size:11pt">Update</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US"><span style="font-size:11pt">New WG in DIF "</span><a href="https://lists.identity.foundation/g/wallet-security" target="_blank"><span style="font-size:11pt">Wallet Security</span></a><span style="font-size:11pt">"
is starting (charter is being drafted) which discusses trust into the wallet is in-scope. Tom said we should monitor the progress in that group to have synergy and avoid overlapping scope with this group.</span></li></ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US"><span style="font-size:11pt">Action items</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US"><span style="font-size:11pt">Write up a more concrete proposal on the discovery and present a prototype at the next call (Jeremie and DW)</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US"><span style="font-size:11pt">Define success criteria for the discovery - number of SIOP SW installed, etc. (Tom and Tim)</span></li></ul>
</ul>
<ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">New
issues</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle"><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)" lang="en-US">Value of iss = <a href="http://self-issued.me" target="_blank">self-issued.me</a> (</span><a href="https://bitbucket.org/openid/connect/issues/1208/siop-v2-dynamic-iss-claim-ref-required" target="_blank"><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)" lang="ja">#1208</span></a><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)" lang="ja">)</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Questions: how to communicate the information about the SIOP SW provider and what is the rationale to use <a href="http://self-issued.me" target="_blank">self-issued.me</a></span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">What is the rationale behind using <a href="http://self-issued.me" target="_blank">self-issued.me</a> as `iss` value?</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Oliver: it was used as a source of static OIDC configuration because SIOP does not have a service endpoint. Questions why <a href="http://self-issued.me" target="_blank">self-issued.me</a> is needed.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">DW: <a href="http://selfissued.me" target="_blank">selfissued.me</a> was not meant to be hit. Original limitations of SIOP when it was created was that only way to invoke a native app from a website was a
custom url scheme. No good IPC channel between them, so redirect was chose.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Justin: goal of using this discovery launch point for SIOP was that all device driven things are started the same way, without knowing what kind of device
you are trying to get to. Another hard issue is that issuer identifier used throughout the protocol is based on the initial discovery. In SIOP it pretends to be HTTP when it actually isn't.</span></li></ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Oliver: any other requirement that RP needs to know discovery endpoint upfront before the authorization request is sent? </span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">DW: You can't control what is kicked off using custom URL scheme. Having individual URL for PWA that is universal link allows to use specific wallet. That
means users have to select which particular wallet they want to use.</span><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
</span><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">No control over what OS vendors would reserve for authentication flows, and this is not a solvable problem, rather tradeoffs.</span><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
</span></li></ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Tom: we could make a unified statement to the browsers what we need - solving the NASCAR problem</span></li></ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><b>Discovery proposal alternative to openid://</b></span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Jeremie: Best effort, not a perfect solution, leans heavily on the platforms. Using the set of APIs that iOS, Android and Windows provide to present the
user with the selection from that is already installed</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Three parts. First, some common website to publish app IDs as authorized apps to open links for a given path that all RPs will target with a new Discovery
request. </span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Second, when user clicks that link, the platform will query that website to discover if there is a local app that will handle the request to that path, it
will open app.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Third, using the platforms' built-in share sheets capability - OS will present a list of applications that can handle that data. Any supporting app registered
to receive that path would ask the OS to present the list of application that can support handling that request.</span></li></ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">DW: analogy is a native app version of CHAPI. What we can do now is <a href="http://self-issued.me" target="_blank">self-issued.me</a> can have metadata file for platforms that says which issuer people can
redirect to rather than openid://, native app on the list will get triggered. Applications from third party app stores would also be able to opt in to receive those requests. Share sheets also work with app-to-app.
</span></li></ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Following discussion</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">Tim: we need to define the success criteria. One or several wallets.</span><br>
</li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">DW: agree. Is the user responsible for maintaining several wallets that may conflict? Need to take into the reality of dependency on the platforms.</span></li></ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Oliver: Can return change the requirement `iss`=<a href="http://self-issued.me" target="_blank">self-issued.me</a> if this new discovery mechanism is adapted? To include DIDs in `iss` for example.</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Justin: Restrictions on the issuer identifier matching come from the discovery specification in OIDC. if a new discovery mechanisms is used, you're not bound
to those same rules. It is fundamental to OIDC and very deliberate that there are two different fields in OIDC - who is the user and who says so.
</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">The two are tightly bound only in so much as a user account is tightly bound to the IdP that asserts that user account. You do not want to constrain self-issued
identifiers by requiring somebody be identified by their device because that is potentially very bad privacy risk, allowing colluding RPs to share information about an individual user.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">DW: issuer and user identities today would have a parallel to user and wallet iidentity attestations in the secure wallet space.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Tom: wallet identifier and wallet instance identifier should be distinguished.</span></li></ul>
</ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Supporting LD-proof signed claims</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle"><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)" lang="en-US">Q</span><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)" lang="ja">uestion
addressed: how to send back VP signed by LD-proofs</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Oliver: proposal of introducing a new artifact vp_token that would represent VCs signed using JWTs/LD-proofs. It would be wise to support LD-proofs to embrace
SSI community and allow new ZKP schemes (BBS+) and other privacy preserving technology that DHS SVIP program actively supports. Vp_token is a cleaner approach that is better from extensibility (additional claims?). Question to the implementers if this is viable. <a href="https://hackmd.io/PZE3__bjT-e3NnjTGK7PHQ?view" rel="nofollow" style="color:rgb(0,101,255);text-decoration:underline;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:14px;background-color:rgb(255,255,255)" id="gmail-m_-90882616163421252LPlnk705040" target="_blank">https://hackmd.io/PZE3__bjT-e3NnjTGK7PHQ?view</a></span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle"><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)" lang="en-US">Kristina:
</span><span lang="ja"><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> </span></span><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)" lang="en-US">introducing
a new scope is a p</span><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)" lang="ja">rotocol change, which has significant ramifications.</span><span lang="ja"><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
</span></span><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)" lang="ja">There would be lots of questions to answer, like what triggers its addition (possibly use of a "claims" request?), what if there
are multiple VPs, etc. </span></li></ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Tony: I would oppose is vp_token is exactly the same as VP, because it may cause a problem processing. There is an issue of no approved algorithms or canonicalization
methods for LD-proofs. ZKP work has been done with JWTs too.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Tom: success of this spec should not be depend</span><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">ent
on the success of DIDs and VPs. You can canonicalize the whole VC/VP by putting it into JOSE structure, expand the header section.
</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Discussion on how much work RPs would have to do to accept LD-proofs - add support for the existing relevant libraries or getting this inside HSM to use
for fundamental features.</span></li></ul>
</ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Call Schedule</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">The next SIOP special topic call is in two weeks at the same time</span></li></ul>
</ul>
</div>
<div dir="ltr">
<div><br>
</div>
<div>
<div><br>
</div>
<div id="gmail-m_-90882616163421252x_appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-90882616163421252x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>差出人:</b> Kristina Yasuda <<a href="mailto:Kristina.Yasuda@microsoft.com" target="_blank">Kristina.Yasuda@microsoft.com</a>><br>
<b>送信日時:</b> 2021年2月4日 14:54<br>
<b>宛先:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a> <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>件名:</b> SIOP Special Call Notes 02-Feb-21</font>
<div> </div>
</div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div>
<blockquote style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;margin-top:0px;margin-bottom:0px">
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">SIOP Special Call Notes 02-Feb-21<br>
</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white"><br>
</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">John Bradley</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Albert Solana</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Justin Richer</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Mike Varley</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Anthony Nadalin</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Torsten Lodderstedt</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Brian Campbell</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Tom Jones</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">David Moeller</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Nader Helmy</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Oliver Terbu</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">David Bantz</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Jeremie Miller</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Adam Lemmon</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Dion Bramley</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Kim Duffy</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Matt Randall</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Bjorn Hjelm</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Tobias Looker</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Edmund Jay</span></div>
<div><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Kristina Yasuda</span></div>
<div><span style="color:rgb(32,31,30);font-family:Calibri;font-size:11pt"><br>
</span></div>
<div><span style="color:rgb(32,31,30);font-family:Calibri;font-size:11pt">Regrets: Mike Jones</span></div>
</blockquote>
<div style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
</div>
<ul style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Introductions</span></li></ul>
<ul style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Agenda Bashing</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Kristina: Today's agenda is to introduce "Portable Identifiers work" and
<span style="background-color:rgb(255,255,255);display:inline">discuss scope and direction</span>: driving use-cases, adoption challenges, workstream name is a misnomer?, and relation to a MODERNA account porting spec</span></li></ul>
</ul>
<ul>
<li style="color:black;font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;margin-top:0px;margin-bottom:0px;vertical-align:middle">
<span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Overview of the Portable Identifiers draft
</span><a href="https://mattrglobal.github.io/oidc-portable-identities/" target="_blank"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">https://mattrglobal.github.io/oidc-portable-identities/</span></a><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">
(WIP): </span></li><ul>
<li style="color:black;font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;margin-top:0px;margin-bottom:0px;vertical-align:middle">
<span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Tobias: The problem addressed is how users can outlive the Provider and be able to transfer identity from one provider to another and what mechanisms are available to make
this possible. Related work is an account porting spec in OIDF MODERNA WG that defines mechanisms to hand-over from one provider to another. </span></li><li style="color:black;font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;margin-top:0px;margin-bottom:0px;vertical-align:middle">
<span style="font-family:calibri;font-size:11pt;color:rgb(32,31,30);background-color:rgba(0,0,0,0)"><b>Mechanism we are exploring is using cryptography to establish proof of control over the subject identifier
</b>to allow transferring ownership and consent of the user. DIDs establish a way to achieve this.</span></li><li style="color:black;font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;margin-top:0px;margin-bottom:0px;vertical-align:middle">
<span style="font-family:calibri;font-size:11pt;color:rgb(32,31,30);background-color:rgba(0,0,0,0)">SIOP, Chapter 7 in OIDC, allows for portability for co-located model, this work tries to expand that to other deployment models</span></li></ul>
</ul>
<ul style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Use-cases motivating the work</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Torsten:<b> SSI is about portability, but no one emphasizes it.</b> Portable identifiers would
provide a way for server cloud hosted wallets to assert DIDs, which is impossible with the scope of SIOP V2 draft which revises OIDC chapter 7 and is optimized for a deployment model where OP and RP are co-located.
</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Torsten: Example of
<b>real life use-case would be British Columbia's prototype</b> where a server-hosted OP uses DIDs and VCs. Would als o like to enable banks in Yes.com ecosystem to assert
</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Question from Kim regarding details of Section 6 "Subject Identifiers"</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Tobias: in OIDC, identifiers are domain bound to the IdP's namespace, but there could be other
types of identifiers: jwk thumbprint is one kind of identifier used in original SIOP section of OIDC and DIDs are another kind.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Kristina:
<b>rough consensus in the WG since the beginning of SIOP revision has been to introduce a layer of indirection to `sub` to allow it to be a URI.</b> With this, DIDs can be used as subject identifiers.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black">
<span style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">Clarification from Tony - "wallets" are not limited to mobile wallets, any server hosted OPs would be able to assert DIDs.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black">
<span style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">Tobias: "wallet" is an overarching term, used in particular deployment models, but the function that it serves is OPs<br>
</span></li></ul>
</ul>
<ul style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="color:rgb(32,31,30);font-family:Calibri;font-size:11pt">Why another attempt at portable identifiers will have a different outcome (than i-names), whether for adoption
by people, adoption by RPs, or adoption by OPs?</span><br>
</li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Tobias: Agrees with Mike's sentiment that normal people don’t care about portable login identifiers.<span>
</span>This is more about identity bound to the provider - trust relationship - does not want to offer
</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">John: with former i-names, problem was with a business model. Given that larger providers
give identifiers for free, paid IdP did not fly. </span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">No </span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">one
is against having portability, but no body was willing to pay extra for it.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Torsten</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">:</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">
No one is willing to pay </span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">for identity
</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">-
</span><b><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">the discussion on
</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">business
</span></b><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white"><b>model is related to the entire SSI-based model
</b>and should be separate from a technical discussion here.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black">
<span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">John</span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">:</span><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white"><span> </span>all
comes down to the key management and asserting identifiers, other things come along to be used</span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">.</span><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white"> Currently, </span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">IdPs
use keys bound to their DNS which means using</span><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white"> single key for all identifiers.<span> </span><b>There is a good reason to abstract that into
being able to use individual keys for individual accounts, separate from a business model discussion.</b></span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black">
<span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">Kim: we are f</span><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">ocusing on a
wrong use case</span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">. In<span> </span></span><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">educational
occupational credentials</span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">,
<b>users </b></span><b><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">care about things remaining usable<span> </span></span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">over</span></b><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white"><b><span> </span>life
time, </b>and they don't care if it's phrased portability</span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">. We just need to expand out to the use cases that benefit from portability.<br>
</span></li></ul>
</ul>
<ul style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white"><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">Is<span> </span></span><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">"Portable
Identifiers"<span> </span></span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">is<span> </span></span><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">a
misnomer</span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">?</span><br>
</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">John: we are n</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">ot
talking about porting identifier themselves</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">, rather that<b> the </b></span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white"><b>cryptographic
keys used to prove control over identifiers are portable</b> and can potentially be used to migrate from one identifier to another.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">John: the naming can be "Portability of cryptographyc proofs to assert control over
identifiers" spec</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Kim: this is not about portable identifiers but portable credentials associated with
an identifier</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Tony:
</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">How do you define portable credentials</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">?</span></li><li lang="en-US" style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black">
<span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">John: identifier is part of a credential, every credential is essentially portable; need to define the language</span></li><li lang="en-US" style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black">
<span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white"><span lang="ja" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">General consensus is yes. Alternative naming suggestions in a
chat: Portability between Identifiers rather than Portable Identifiers</span><span lang="en-US" style="margin:0px;font-size:11pt;font-family:Calibri;color:rgb(32,31,30);background:white">; Inter-Identifier Portability (IIP)</span></span></li></ul>
</ul>
<ul style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<li lang="en-US" style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black">
<span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">W</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">hat
changes would be required from </span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">OpenID
Connect RPs</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">
to support 'portable identifiers'</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">?</span><br>
</li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">As e</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">xplored
in the </span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Portable Identifiers
</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">draft</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">,</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">
RP</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">s</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white"> would
</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">have to
</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">expand client metadata element</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">s indicating support
for supported subject identifier types and did methods. <b>ID token would be fundamentally signed by the provider who is performing the authentication, but there would be a separate claim in the ID token that proves user's control over the subject identifier.</b> </span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Worst
scenario - RP would assume identifier is tied to the provider (instead of a user)</span></li></ul>
</ul>
<ul style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">W</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">hat
changes would be required from </span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">OpenID Connect
</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">O</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Ps</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">
to support 'portable identifiers'</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">?</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">OP</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">
would need to </span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">support cryptographically verifiable subject identifiers - including DIDs. And advertising support for those features through OIDC discovery
mechanisms</span></li></ul>
</ul>
<ul style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<li lang="en-US" style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black">
<span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">No comments regarding the usage of VCs/VPs in OIDC</span></li></ul>
<ul style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Can this be a profile to MODERNA Account Porting spec?
</span></li><ul>
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">General consensus is no,
<b>this should be a separate work due to a differences in </b></span><b><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">concept
</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">and approach.</span></b></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">John: In MODERNA complete cryptographic proof is not used though it was considered
because you have an Old OP to provide look up services. We should not be constrained by the choices MODERNA made.</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Bjorn: MODERNA porting is based on migration mechanism from OpenID 2.0 to OpenID
Connect. a</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">ccount porting
</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">spec is
</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">written
</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">in a
</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">very flexible
</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">way</span></li><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle;color:black"><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">Torsten: co-author of account porting spec - the spec assumes that</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">
old OP is still operational </span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">even after</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white"> account porting
has happened</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">. Another big difference with Portable identifiers spec is the fact that in account porting spec, i</span><span lang="ja" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">dentifier
is always scoped in the name space of IdP - not the case with DIDs</span><span lang="en-US" style="font-family:Calibri;font-size:11pt;color:rgb(32,31,30);background:white">.</span></li></ul>
</ul>
</div>
<br>
</div>
<div><span style="font-family:calibri;font-size:11pt;color:rgb(32,31,30);background-color:rgba(0,0,0,0)">Minutes can also be found in Connect WG Bitbucket Wiki: </span><a href="https://bitbucket.org/openid/connect/wiki/SIOP%20Special%20Call%20Notes%2002-Feb-21" id="gmail-m_-90882616163421252LPlnk375037" target="_blank"><span style="font-family:calibri;font-size:11pt;color:rgb(32,31,30);background-color:rgba(0,0,0,0)">https://bitbucket.org/openid/connect/wiki/SIOP%20Special%20Call%20Notes%2002-Feb-21</span></a></div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
<br>
<pre style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;white-space:pre-wrap;background-color:rgb(255,255,255);font-size:14px">This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.</pre>