<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Adam Lemmon</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div>Alen Horvat</div>
<div>Oliver Terbu</div>
<div>Tom Jones</div>
<div>Torsten Lodderstedt</div>
<div>Tim Cappalli</div>
<div>David Waite</div>
<div>Vittorio Bertocci</div>
<div>Jeremie Miller</div>
<div>Balazs Nemeti (DIF)</div>
<div>Erik Zvaigzne (Convergence tech)</div>
<div>Anthony Nadalin</div>
<div>Justin Richer</div>
<div>Kaliya Young</div>
<div>Kristina Yasuda</div>
<div><br>
</div>
<div>- regrets: Mike, John, Nat</div>
<div>- Introductions: Balazs, works at DIF</div>
<div><br>
</div>
<div>- In PDT, the time of the calls are at 3pm from this week. </div>
<div><br>
</div>
<div>Agenda: Issue Discussion #1212 Universal URL based discovery for SIOP <span style="background-color:rgb(255, 255, 255);display:inline !important"><a href="https://bitbucket.org/openid/connect/issues/1212/universal-url-based-discovery-for-siop" id="LPlnk">https://bitbucket.org/openid/connect/issues/1212/universal-url-based-discovery-for-siop</a></span></div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>
<div><br>
</div>
<div>Overview of the proposal/initial Q&A</div>
<div>
<ul>
<li>- Jeremie gave overview of a proposal. A practical approach that tackles user experience issue with openid:// with what is available today.</li><li>- Two aspects to the proposal: 1/letting the user choose the application; 2/handling multiple apps.</li><li>- 1st aspect: RP wants to provide a user a choice of which app they might use SIOP with: can be mobile app or PWA. To prevent a NASCAR screen, it can be a discovery endpoint that provides linking into an app/PWA a user chose to install (universal links)
</li><li>- RP links to a URL of the shared site that contains metadata of the identifiers for all of the applications that can satisfy that request. If the user have chosen one, it will be automatically launched. If not, the user will be displayed with the option
of available apps/PWAs</li><li>- Tom: This can potentially be a very long list (on the shared site)?</li><li>- Jeremie: Kristina and Pam suggested that this solution is best applied within a trust framework that RP belongs to.
</li><li>- Tom volunteered to provide such trust framework for the healthcare.</li><li>- Alen: Two questions: 1. this can be a single point of failure. 2. Who would be responsible for paying and managing all the traffic.</li><li>- Jeremie: this site will handle only the request. and if the user has an app installed natively, the site does not even get a request and. very little traffic unless user does not have an app and needs to discover.</li></ul>
</div>
<div><br>
</div>
<div>Demo by DW</div>
<div>
<ul>
<li>- [Demo 1] David showed a screen with Apple app metadata cashed by Apple that indicates which apps are able to take control of the authorize path on this particular server.
</li><li>- David showed a not very helpful error screen that using openid:// option gives if user does not have a wallet installed. potential attack surface for fishing if a malicious app gets invoked first.</li><li>- With universal links, if no app installed, user gets a list of potential applications and how to use them (including PWAs)</li><li>- David installed an app real time. Now when user clicks a log-in link at the RP website, user is taken directly into a native application, authentication is performed and user is taken back to the RP.</li><li>- (going between web-based flow and Native app flow using universal links instead of custom URL schemes)</li><li>- openid:// does not let you choose which app to open. In this proposal, there is a predictable behavior, but it is a prioritized list.
</li><li>- [Demo 2] brewery app asking for the proof of age. User is presented with a screen with an option to install an app or use already installed State Identity Card. Uses Share Sheet functionality, based on the metadata that applications have at publication
time about what kind of files they can deal with.</li><li>- proof of age got shared right away because user has consented through the OS mechanism</li><li>- for proof of age, passport and state id apps were options, but for shipping address, only state id app depending on the claims supported.</li><li>- presentation exchange not used.</li><li>- the app does not know which RP requested the address.</li><li>- Kristina is looking for a way to share the recording of the demo publicly. </li></ul>
</div>
<div><br>
</div>
<div>Discussion</div>
<div></div>
<div>
<ul>
<li>Share Sheets<br>
</li><li>- Oliver: How do you find the sharesheet provider? on iOS, Android, Windows, native versions of sharesheet capability exists. On Mac could be limiting, but can use.</li><li>- David: Have talked to Apple and this proposal uses more features than usual apps, but is not against any rules. Share Sheet functionality is important because app store (and probably users) will reject any app that require another particular app (App
A using only App B for authenticaiton for example). Have been working on app-to-app scenario for a while.</li></ul>
</div>
<div>
<ul>
<li>[Comments in chat how this would work reliably today, but OS vendors, Browsers could change things anytime without prior notice]</li><li>- Tim: Apple and Google's participation is required. We need a broker mechanism at the OS level. OIDF level engagement is needed.</li><li>- Jeremie: yes, the motivation of this work is to build something demonstrable, show that this is workable using the native capability, but not ideal, and ncourage OS vendor's participation to improve.
</li><li>- DW: privacy centric browsers, not very keen to rely on several large social networks should be interested in this new scenarios and enabling users to bring their own identity. Apple and Google would want to be on the broker list if they want to broker
identity.</li><li>- Tim: Apple and Google do not want you to bring your identity. (responding to a comment in chat that Apple and Google are working on vaccination credentials) there is a fundamental difference between gaining access to an app and passing information securely
attested information.</li><li>- Kristina: identifying use-cases would be very important</li><li>- Justin: the most important thing is to get RPs to accept this. It was the case with OpenID Connect too. This has to be part of the conversation here.</li></ul>
<ul>
<li>- Jeremie: opportunity is that discussion is shifting toward credentials which is different from authenticating and identifying yourself. and Google and Apple are not sources of those credentials.</li><li>- DW: Does not see VC used for strong authentication, but looks at them as strongly attested attributes used for account recovery, or the link secret used to generate stable pseudonyms. how do I know DIDAuth is string enough? WebAuthn is strong enough,
but it falls flat in recovery. Using strongly attested credentials tied not to the HW, but to the account for example could be used for the recovery.</li></ul>
</div>
<div>
<ul>
<li>- Alen: Two questions. 1/ interop btw issuers and RPs. How does RP know how to validate credential from the issuer? 2/ what if RP accepts credentials only from the certified wallets and user has a needed credential in a non-certified wallet. Can I move
a credential from one wallet to another? </li><li>- DW: req can be richer, list of wallets can be filtered, to leave only those that can handle credentials requested by RP. (schema would have to be pre-agreed btw the RP and issuer) You will web-based fallback option - if a user does not have a credential
RP wants, it can download a suitable wallet and get the credential. </li><li>- Both the domain has to say they want the app and hte app has to say they want to support universal links from the domain</li></ul>
<ul>
<li>- Balazs encouraged participants to review the charter of Wallet security WG in DIF that</li><li><span style="margin:0px;background-color:rgb(255, 255, 255)">- Information for Wallet Security WG in DIF. Members are encouraged to comment on the charter.</span></li><ul>
<li style="margin:0px;background-color:rgb(255, 255, 255)"> <span> </span><a href="https://docs.google.com/document/d/18H2hVjHZEBjbnzod8tLogJIEzySdecbk9d-QBJaqHP0/edit" title="https://docs.google.com/document/d/18H2hVjHZEBjbnzod8tLogJIEzySdecbk9d-QBJaqHP0/edit" style="margin:0px">WG
Charter</a> (Draft) - planned to be finalized in the next call on22nd of March.</li><li style="margin:0px;background-color:rgb(255, 255, 255)"> <span> </span><a href="https://lists.identity.foundation/g/wallet-security" title="https://lists.identity.foundation/g/wallet-security" style="margin:0px">Mailing list</a></li><li style="margin:0px;background-color:rgb(255, 255, 255)"> <span> </span><a href="https://docs.google.com/forms/d/e/1FAIpQLSffkKj7nqndevSXvPNg_Q3a9MVqBhJvqatl88TnlX1L-WLUDA/viewform" title="https://docs.google.com/forms/d/e/1FAIpQLSffkKj7nqndevSXvPNg_Q3a9MVqBhJvqatl88TnlX1L-WLUDA/viewform" style="margin:0px">Register
for drafting sessions</a>(Calendar invite)</li><li><span style="margin:0px;background-color:rgb(255, 255, 255)"> Would need to find a way to prevent overlaps in scope and deliverables</span></li></ul>
</ul>
<ul>
<li>- Jeremie said he would update the issue with today's feedback.</li></ul>
</div>
Notes are also in the Bitbucket Wiki: <a href="https://bitbucket.org/openid/connect/wiki/2021-03-16" id="LPlnk299180">openid / connect / wiki / 2021-03-16 — Bitbucket</a></div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Big thank you to Jeremie and DW for the demo!</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>差出人:</b> Kristina Yasuda <Kristina.Yasuda@microsoft.com><br>
<b>送信日時:</b> 2021年3月8日 14:51<br>
<b>宛先:</b> openid-specs-ab@lists.openid.net <openid-specs-ab@lists.openid.net><br>
<b>件名:</b> SIOP Special Call Notes 02-March-21</font>
<div> </div>
</div>
<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">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="x_divRplyFwdMsg" dir="ltr">
<ul>
<li><span> <span style="font-size:11pt">IPR Agreement</span></span></li><ul>
<li lang="en-US" style="margin-top:0; margin-bottom:0; vertical-align:middle"><span style="font-size:11.0pt">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/"><span style="font-size:11.0pt">https://openid.net/intellectual-property/</span></a><span style="font-size:11.0pt">. 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 lang="en-US" style="margin-top:0; margin-bottom:0; vertical-align:middle"><span style="font-size:11.0pt">Update</span></li><ul>
<li lang="en-US" style="margin-top:0; margin-bottom:0; vertical-align:middle"><span style="font-size:11.0pt">New WG in DIF "</span><a href="https://lists.identity.foundation/g/wallet-security"><span style="font-size:11.0pt">Wallet Security</span></a><span style="font-size:11.0pt">"
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 lang="en-US" style="margin-top:0; margin-bottom:0; vertical-align:middle"><span style="font-size:11.0pt">Action items</span></li><ul>
<li lang="en-US" style="margin-top:0; margin-bottom:0; vertical-align:middle"><span style="font-size:11.0pt">Write up a more concrete proposal on the discovery and present a prototype at the next call (Jeremie and DW)</span></li><li lang="en-US" style="margin-top:0; margin-bottom:0; vertical-align:middle"><span style="font-size:11.0pt">Define success criteria for the discovery - number of SIOP SW installed, etc. (Tom and Tim)</span></li></ul>
</ul>
<ul>
<li lang="en-US" style="margin-top:0px; margin-bottom:0px; vertical-align:middle">
<span style="background-image:initial; background-position:initial; background-size:initial; background-repeat:initial; background-attachment: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 lang="en-US" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Value of iss = self-issued.me (</span><a href="https://bitbucket.org/openid/connect/issues/1208/siop-v2-dynamic-iss-claim-ref-required"><span lang="ja" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">#1208</span></a><span lang="ja" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">)</span></li><ul>
<li lang="en-US" 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)">Questions: how to communicate the information about the SIOP SW provider and what is the rationale to use self-issued.me</span></li><li lang="en-US" 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)">What is the rationale behind using self-issued.me as `iss` value?</span></li><ul>
<li lang="en-US" 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)">Oliver: it was used as a source of static OIDC configuration because SIOP does not have a service endpoint. Questions why self-issued.me is needed.</span></li><li lang="en-US" 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)">DW: selfissued.me 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 lang="en-US" 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)">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 lang="en-US" 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)">Oliver: any other requirement that RP needs to know discovery endpoint upfront before the authorization request is sent? </span></li><ul>
<li lang="en-US" 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)">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 lang="en-US" 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)">Tom: we could make a unified statement to the browsers what we need - solving the NASCAR problem</span></li></ul>
<li lang="en-US" 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)"><b>Discovery proposal alternative to openid://</b></span></li><ul>
<li lang="en-US" 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)">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 lang="en-US" 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)">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 lang="en-US" 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)">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 lang="en-US" 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)">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 lang="en-US" 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)">DW: analogy is a native app version of CHAPI. What we can do now is self-issued.me 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 lang="en-US" 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)">Following discussion</span></li><ul>
<li lang="en-US" style="margin-top:0px; margin-bottom:0px; vertical-align:middle">
<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 lang="en-US" 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)">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 lang="en-US" 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)">Oliver: Can return change the requirement `iss`=self-issued.me if this new discovery mechanism is adapted? To include DIDs in `iss` for example.</span></li><ul>
<li lang="en-US" 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)">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 lang="en-US" 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)">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 lang="en-US" 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)">DW: issuer and user identities today would have a parallel to user and wallet iidentity attestations in the secure wallet space.</span></li><li lang="en-US" 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)">Tom: wallet identifier and wallet instance identifier should be distinguished.</span></li></ul>
</ul>
<li lang="en-US" 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)">Supporting LD-proof signed claims</span></li><ul>
<li style="margin-top:0px; margin-bottom:0px; vertical-align:middle"><span lang="en-US" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Q</span><span lang="ja" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">uestion
addressed: how to send back VP signed by LD-proofs</span></li><li lang="en-US" 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)">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 class="x_ap-connect-link" href="https://hackmd.io/PZE3__bjT-e3NnjTGK7PHQ?view" rel="nofollow" id="LPlnk705040" style="color:rgb(0,101,255); text-decoration:underline; font-size:14px; background-color:rgb(255,255,255)">https://hackmd.io/PZE3__bjT-e3NnjTGK7PHQ?view</a></span></li><ul>
<li style="margin-top:0px; margin-bottom:0px; vertical-align:middle"><span lang="en-US" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Kristina:
</span><span lang="ja" style=""><span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> </span></span><span lang="en-US" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">introducing
a new scope is a p</span><span lang="ja" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">rotocol change, which has significant ramifications.</span><span lang="ja" style=""><span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
</span></span><span lang="ja" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">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 lang="en-US" 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)">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 lang="en-US" 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)">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 lang="en-US" 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)">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 lang="en-US" 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)">Call Schedule</span></li><ul>
<li lang="en-US" 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)">The next SIOP special topic call is in two weeks at the same time</span></li></ul>
</ul>
</div>
<div dir="ltr">
<div style=""><br>
</div>
<div>
<div style=""><br>
</div>
<div id="x_x_appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>差出人:</b> Kristina Yasuda <Kristina.Yasuda@microsoft.com><br>
<b>送信日時:</b> 2021年2月4日 14:54<br>
<b>宛先:</b> openid-specs-ab@lists.openid.net <openid-specs-ab@lists.openid.net><br>
<b>件名:</b> SIOP Special Call Notes 02-Feb-21</font>
<div> </div>
</div>
<div dir="ltr">
<div>
<div dir="ltr">
<div style="">
<div style="">
<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:11.0pt; color:#201F1E; background:white">SIOP Special Call Notes 02-Feb-21<br>
</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white"><br>
</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">John Bradley</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Albert Solana</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Justin Richer</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Mike Varley</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Anthony Nadalin</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Torsten Lodderstedt</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Brian Campbell</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Tom Jones</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">David Moeller</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Nader Helmy</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Oliver Terbu</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">David Bantz</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Jeremie Miller</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Adam Lemmon</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Dion Bramley</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Kim Duffy</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Matt Randall</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Bjorn Hjelm</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Tobias Looker</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Edmund Jay</span></div>
<div><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Agenda Bashing</span></li><ul>
<li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Kristina: Today's agenda is to introduce "Portable Identifiers work" and
<span style="background-color:rgb(255,255,255); display:inline!important">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 style="">
<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:11.0pt; color:#201F1E; background:white">Overview of the Portable Identifiers draft
</span><a href="https://mattrglobal.github.io/oidc-portable-identities/"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">https://mattrglobal.github.io/oidc-portable-identities/</span></a><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">
(WIP): </span></li><ul style="">
<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:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Use-cases motivating the work</span></li><ul>
<li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Question from Kim regarding details of Section 6 "Subject Identifiers"</span></li><li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Tobias: Agrees with Mike's sentiment that normal people don’t care about portable login identifiers.<span style="">
</span>This is more about identity bound to the provider - trust relationship - does not want to offer
</span></li><li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:11.0pt; color:#201F1E; background:white">No </span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">one
is against having portability, but no body was willing to pay extra for it.</span></li><li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Torsten</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">:</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">
No one is willing to pay </span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">for identity
</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">-
</span><b><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">the discussion on
</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">business
</span></b><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">John: we are n</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">ot
talking about porting identifier themselves</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">, rather that<b> the </b></span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">John: the naming can be "Portability of cryptographyc proofs to assert control over
identifiers" spec</span></li><li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Kim: this is not about portable identifiers but portable credentials associated with
an identifier</span></li><li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Tony:
</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">How do you define portable credentials</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">?</span></li><li lang="en-US" style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black">
<span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black">
<span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; 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-attachment: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-attachment: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-attachment: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-attachment: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-attachment:initial; background-origin:initial; background-clip:initial">?</span><br>
</li><ul>
<li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">As e</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">xplored
in the </span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Portable Identifiers
</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">draft</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">,</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">
RP</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">s</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white"> would
</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">have to
</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">expand client metadata element</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">W</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">hat
changes would be required from </span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">OpenID Connect
</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">O</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Ps</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">
to support 'portable identifiers'</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">?</span></li><ul>
<li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">OP</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">
would need to </span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black">
<span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Can this be a profile to MODERNA Account Porting spec?
</span></li><ul>
<li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:11.0pt; color:#201F1E; background:white">concept
</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">and approach.</span></b></li><li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:11.0pt; color:#201F1E; background:white">ccount porting
</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">spec is
</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">written
</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">in a
</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">very flexible
</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">way</span></li><li style="margin-top:0; margin-bottom:0; vertical-align:middle; color:black"><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">Torsten: co-author of account porting spec - the spec assumes that</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">
old OP is still operational </span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white">even after</span><span lang="ja" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; background:white"> account porting
has happened</span><span lang="en-US" style="font-family:Calibri; font-size:11.0pt; color:#201F1E; 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:11.0pt; color:#201F1E; 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:11.0pt; color:#201F1E; background:white">.</span></li></ul>
</ul>
</div>
<br>
</div>
<div style=""><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="LPlnk375037" style=""><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>
</body>
</html>