<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-2022-jp">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style=""><span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;"><span style="margin:0px">Oliver Terbu</span></span>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
<span style="margin:0px">Mike Jones</span></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
<span style="margin:0px">Dmitri Zagidulin</span></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
<span style="margin:0px">Jo Vercammen</span></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
<span style="margin:0px">Jan Vereecken</span></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
<span style="margin:0px">Nat Sakimura</span></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
<span style="margin:0px">Andrew Hughes</span><br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
<span style="margin:0px">Torsten Lodderstedt</span></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
<span style="margin:0px">Adam Lemmon</span></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
Kristina Yasuda</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; margin: 0px;">
<br>
</div>
<div style="margin: 0px;">
<div style="margin: 0px;">
<ul style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background-color: white;">
<li>Decisions</li><ul>
<li><b>Updated Call schedule:</b> <span style="text-align:start;background-color:rgb(255, 255, 255);display:inline !important">weekly</span><span style="margin:0px;text-align:start;background-color:rgb(255, 255, 255)"> </span><span data-markjs="true" class="marki35erawos" data-ogac="" data-ogab="" data-ogsc="" data-ogsb="" style="margin:0px;text-align:start;background-color:rgb(255, 255, 255)">SIOP</span><span style="margin:0px;text-align:start;background-color:rgb(255, 255, 255)"> </span><span style="text-align:start;background-color:rgb(255, 255, 255);display:inline !important">calls
alternating between Atlantic and Pacific timezones</span></li><ul>
<li>Bi-Weekly Pacific<span> </span><span data-markjs="true" class="marki35erawos" data-ogac="" data-ogab="" data-ogsc="" data-ogsb="" style="margin:0px">SIOP</span><span> </span>calls on the usual time (7AM JST, 3PM PST) on Tuesday starting May 4th -> 18th
-> June 1st -> ...</li><li>Bi-Weekly Atlantic<span> </span><span data-markjs="true" class="marki35erawos" data-ogac="" data-ogab="" data-ogsc="" data-ogsb="" style="margin:0px">SIOP</span><span> </span>calls on the time as the first call today (11PM JST, 7AM PST), but on Thursday,
starting May 13th -> 27th -> June 10th -> ... (filling in the empty slot for the bi-weekly Atlantic Connect calls)</li><li><b>OIDF and DIF calendars will be updated soon. You should have already received invites from me.</b></li></ul>
<li>
<div style="margin:0px;text-align:start;background-color:rgb(255, 255, 255)"></div>
<div style="margin:0px;text-align:start;background-color:rgb(255, 255, 255)"><span style="margin:0px"><span style="margin:0px">Requesting and presentating of VCs using OIDC aka <span style="background-color:rgb(255, 255, 255);display:inline !important">OIDC4VCOs<span> </span></span></span></span></div>
</li><ul>
<li>
<div style="margin:0px;text-align:start;background-color:rgb(255, 255, 255)"><span style="margin:0px"><span style="margin:0px">The editors of
<a href="https://github.com/awoie/vp-token-spec" title="https://github.com/awoie/vp-token-spec">
the current draft</a> will contribute the updated version which </span></span>allows for both options - embedding VP inside the ID Token and returning VP separately from ID Token as a newly defined VP Token artifact.</div>
</li><li>
<div style="margin:0px;text-align:start;background-color:rgb(255, 255, 255)">The WG will gather implementation feedback with a goal of making a decision on which option to adopt</div>
</li><li>This specification will be separate from SIOP V2 draft because it applies to not just SIOP flows, and should remain in close touch with issuance of VCs using OIDC work</li></ul>
</ul>
</ul>
<ul style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background-color: white;">
<li>Introductions and Reintroduction</li><ul>
<li><a href="https://www.meeco.me/" title="https://www.meeco.me/">Meeco</a> is joining OIDF </li><ul>
<li>Jo and Jan from Meeco joined the call</li></ul>
<li>Andrew Hughes from Idemia joined the calls - vast experience also in ISO/IEC SC27 WG5, SC17 and FIDO</li></ul>
<li>Meeco Implementations</li><ul>
<li>Implementation in Australia to issue certain credentials (driver licenses) in a way that can be used to verify workers in certain industries</li><li>Another use-case where Verifiable Credential is in a wallet and users present it in a liquor shop as a VP.<br>
</li><li>OIDC is used for issuing of the credential. Flow being used is third party flow, not SIOP flow</li><li>broker translates VCs into OpenID Flow and verifies them.</li><li>chose OIDC to solve the configuration problem, not to eradicate central IdP as in SIOP</li></ul>
<li>SIOP-related sessions @ IIW recap (some happened during 2021-04-26 Connect WG call)</li><ul>
<li>OIDC4VCOs: <a href="https://docs.google.com/presentation/d/1a6xAY9NKNON49Atcv9PtB3F0NdmJ4wDHMrVSPaA2-lI/edit#slide=id.p" style="margin:0px">https://docs.google.com/presentation/d/1a6xAY9NKNON49Atcv9PtB3F0NdmJ4wDHMrVSPaA2-lI/edit#slide=id.p</a></li><li>OpenID Connect Claims Provider: <a href="https://docs.google.com/presentation/d/1w-rmwZoLiFWczJ4chXuxhY0OsgHQmlIimS2TNlce4UU/edit#slide=id.gd331646bb4_0_21" style="margin:0px">https://docs.google.com/presentation/d/1w-rmwZoLiFWczJ4chXuxhY0OsgHQmlIimS2TNlce4UU/edit#slide=id.gd331646bb4_0_21</a><br>
</li><ul>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1" style="margin:0px">
</div>
</ul>
<li>SIOP use-cases: <a href="https://docs.google.com/presentation/d/1a0C4HvVYwwwDqSw3tgPNhy9Iqyufy9oZdnMgl7rQ9Vc/edit#slide=id.p" style="margin:0px">https://docs.google.com/presentation/d/1a0C4HvVYwwwDqSw3tgPNhy9Iqyufy9oZdnMgl7rQ9Vc/edit#slide=id.p</a>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview_1 _EReadonly_1" style="margin:0px">
</div>
</li><li>SIOP Chooser: <a href="https://docs.google.com/presentation/d/1OaMecHecTUexv1skJZoYzJoHKYH8H03REFpFstLRjPg/edit#slide=id.gd2c45a9dcd_7_0" style="margin:0px">https://docs.google.com/presentation/d/1OaMecHecTUexv1skJZoYzJoHKYH8H03REFpFstLRjPg/edit#slide=id.gd2c45a9dcd_7_0</a></li><ul>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview_2 _EReadonly_1" style="margin:0px">
</div>
</ul>
</ul>
<li>Full discussion on <span style="margin:0px;background-color:rgb(255, 255, 255)"><span style="margin:0px"><span style="margin:0px">Requesting and presentating of VCs using OIDC aka <span style="margin:0px;background-color:rgb(255, 255, 255);display:inline !important">OIDC4VCOs<span style="margin:0px"> </span></span></span></span></span></li><ul>
<li>Torsten summarized the develpment to-date</li><ul>
<li>During the IIW session, option 2 on using aggregated/distributed claims syntax got voted out.</li><li>Participants (over 60 people) were split between embedding VP in the ID token and separate VP Token approach (10 votes to 8 votes) </li><li>Vote seems to show a balance between the number of people focussing on (1) ease of adoption in existing implementations vs the number of people focussing on (2) the best technical solution.<br>
</li><ul>
<li>Clarification was requested why VP token approach is considered more "robust".</li></ul>
<li>Initial research showed that SIOP implementations are not using traditional libraries, and are<span style="background-color:rgb(255, 255, 255);display:inline !important"><span> </span>writing code from scratch,
</span>so implementing VP Token should not be an issue; and some providers are willing to try implement VP Token approach</li><li>Proposal to carry on with a version that allows for both options and gather implementation feedback and data and make a decision</li><ul>
<li>would have to define generic container to convey a claim as a same syntax to use when embedding inside the ID token and as a VP token</li><li>something like an array with objects containing a format identifier and the actual payload (+ potentially some additional metadata).</li></ul>
</ul>
<li>Mike commented he is ok, and this reminds him of RFC6750 Bearer Token spec with three ways. It hurts interoperability but allows people to do what they wanted to do.</li><li>Oliver and Dimitri raised a question how do we structure the related specs? </li><ul>
<li>Mike suggested that claims definitions and separate artifact definitions should be in the same spec. Should not be part of SIOP because this is independent from SIOP model. </li><li>Torsten suggeted this work should be alidned with VC issuance using OIDC. </li><li>Nat agreed, no one objected.</li></ul>
<li>Nat asked from which endpoint the VP token will be returned. </li><ul>
<li>Torsten clarified that depends on the grant/response_token. VP token is to be returned as part of authentication response for both SIOP and code flow together with ID Token. </li><li>Returning VP Token from a userInfo or newly defined endpoint could also be considered later. Claims aggregation and Credential Provider draft defined new endpoint, which could potentially be reused.<br>
</li></ul>
<li><span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">Torsten expressed concern regarding issuing credentials in the backchannel using bearer tokens, and not sender constrained access tokens</span><br>
</li><li>Mike asked if we would need to return VCs and to define VC Token too</li><ul>
<li>Oliver and Dimitri argued that VCs should not be returned by themselves - just like claims have to be included inside the ID token</li><li><span style="background-color:rgb(255, 255, 255);display:inline !important">might be no need for VC_token, because </span>if you want to issue a verifiable credential, you can put it inside a VP token</li></ul>
<li>The WG agreed editors will contribute an updated draft to the WG, get recommendation from SIOP Special call to adopt it and officially ask Connect WG to adopt it, so that the draft moves to an official Bitbucket repository and <span style="background-color:rgb(255, 255, 255);display:inline !important">issues
can be raised<span> against it<br>
</span></span> </li></ul>
<li><span style="margin:0px">Events: OIDF Workshop Presentation on April 29th</span></li><ul>
<li><span style="margin:0px">please review the deck planned to be used:<span style="margin:0px"> </span><a href="https://drive.google.com/file/d/1I7QYS8tFd2KHpGKZ0x_8E-95Gc2CeKp7/view?usp=sharing" target="_blank" rel="noopener noreferrer" data-auth="NotApplicable" data-linkindex="0" style="margin:0px">https://drive.google.com/file/d/1I7QYS8tFd2KHpGKZ0x_8E-95Gc2CeKp7/view?usp=sharing<br>
</a></span></li></ul>
</ul>
<div style=""><span style="margin: 0px; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I will also put these notes in the wiki.</span></div>
<div style=""><span style="margin: 0px; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style=""><span style="margin: 0px; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Best,</span></div>
<div style=""><span style="margin: 0px; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Kristina</span></div>
<div style=""><span style="margin: 0px; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
</div>
</div>
<br>
</div>
<div id="appendonsend"></div>
<div style=""><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:9=P?M(B:</b> Kristina Yasuda <Kristina.Yasuda@microsoft.com><br>
<b>$BAw?.F|;~(B:</b> 2021$BG/(B4$B7n(B14$BF|(B 13:27<br>
<b>$B08@h(B:</b> openid-specs-ab@lists.openid.net <openid-specs-ab@lists.openid.net><br>
<b>$B7oL>(B:</b> SIOP Special call notes 13-April-21 Fw: [Openid-specs-ab] OpenID Connect for W3C Verifiable Credential Objects</font>
<div> </div>
</div>
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255); font-family:Calibri,Helvetica,sans-serif">Hi All,</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255); font-family:Calibri,Helvetica,sans-serif"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255); font-family:Calibri,Helvetica,sans-serif">Please find below the note from today's SIOP Special call. </span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
We have three options on how to include W3C Verfiable Credential Objects in OIDC - separate tokens, credential sources (library), and custom claim names. <span style="background-color:rgb(255,255,255); display:inline!important">Attaching the notes to an email
with the relevant slides and links that Torsten kindly shared.</span></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)">
Looking forward to the discussion at IIW.</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)">
<b>Note that the next call will be on 27th at Europe-friendly Atlantic time</b><span style="font-family:Calibri,Helvetica,sans-serif; text-align:left; background-color:rgb(255,255,255); display:inline!important"><span> </span>(7am PST, 5pm CET, 0AM JST).</span></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)">
Best,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Kristina</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt"><span style="margin:0px"><span style="margin:0px; font-family:Calibri,Helvetica,sans-serif">PS Notes can also be found in the Wiki: </span><span style="margin:0px; font-family:Calibri,Helvetica,sans-serif"><a href="https://bitbucket.org/openid/connect/wiki/SIOP%20Special%20call%202021-04-13" style="margin:0px">https://bitbucket.org/openid/connect/wiki/SIOP%20Special%20call%202021-04-13</a></span></span></span><br>
<span style="margin:0px; font-size:12pt"></span><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255); font-family:Calibri,Helvetica,sans-serif"><span style="background-color:rgb(255,255,255); display:inline!important"></span></span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255); font-family:Calibri,Helvetica,sans-serif">---</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255); font-family:Calibri,Helvetica,sans-serif"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255); font-family:Calibri,Helvetica,sans-serif">Mike Jones</span>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Adam Lemmon</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tom Jones</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Anthony Nadalin</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Justin Richer</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tim Cappalli</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">John Bradley</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Jeremie Miller</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Torsten Lodderstedt</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Oliver Terbu</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">David Waite</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Vittorio Bertocci</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tobias Looker</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Bjorn Hjelm</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Edmund Jay</span></div>
<div style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Kristina Yasuda</span></div>
<div style="margin:0px; font-size:14px; background-color:rgb(255,255,255)">
<div dir="ltr" style="margin:0px">
<div style="margin:0px">
<ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Proposal to set up a Europe-friendly SI</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">OP special call time</span></li><ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">same time as Atlantic calls (7am PST, 5pm CET, 0AM JST) on Tuesday, bi-weekly cadence, </span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; display:inline!important">starting
27th April</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; display:inline!important">.<br>
</span></li></ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Update for </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1212%2Funiversal-url-based-discovery-for-siop&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C3a64af5de9524b4ea87b08d8fed02d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539517352090693%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5eeT6I4YFavEacR6f90jGYDFz9%2BgLqY5lL76cVV2k%2Bk%3D&reserved=0" originalsrc="https://bitbucket.org/openid/connect/issues/1212/universal-url-based-discovery-for-siop" shash="oQVGCoBeN7oQGm2cwUjgZamoFdrY+dD6oODUrAsx5V03vOM+9T/jaDuFhZP4DRZNYbKfq8CFRR8rbkly22K+fvzMS6qAAz57yAAJKfQyQwgBVVknJQxmSLjttvrNuLlkSoAfm+A3pBzEdplUlE/FN6FHYFQsRX0NnVYNEetj4CI=" style="margin:0px"><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">#1212
- Universal URL Based Discovery for SIOP</span></a><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></li><ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">Jeremie - working on it; agreed to rename the issue to "SIOP Chooser"</span><br>
</li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">First implementation by Tom Jones - seems to work plan to use MSFT hello as a proof of presence</span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">Some conversation happening over DIF C&C channel</span><br>
</li></ul>
<li style="font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Defining JWT Claims to represent W3C Verifiable Credentials objects discussion</span></li><ul>
<li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Summary of the discussions up to date (see</span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span><span style="margin:0px; font-family:Calibri,Helvetica,sans-serif; background-color:rgb(255,255,255); display:inline!important; font-size:12pt">Spec
Call Notes 8-Apr-21,</span><span style="margin:0px; font-family:calibri,arial,helvetica,sans-serif; background-color:rgb(255,255,255); display:inline!important"><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Spec
Call Notes 12-Apr-21 and ML for details)</span></li><ul>
<li><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Mike: vc vp claims defined in vc-data-model spec do not encompass entire VCs VPs, rather the function to contain JWT claims specific to VC alongside other JWT claims</span></li><li><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Dmitri Zagudulin gave input that there are implementations that embed entire VC VPs </span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">the question being discussed not is do we want IANA registered claims or data structure with dictionaries like </span><span style="margin:0px; font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif"><span style="margin:0px; background-color:rgb(255,255,255); display:inline!important; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">aggregated/distributed
claims syntax</span></span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">.</span><br>
</li><li><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">VC/VPs can be embedded in a JWT as long as their processing rulesare compatible with the enclosing JWT</span></li></ul>
<li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Torsten presented </span><span style="margin:0px; font-size:12pt; background-color:rgb(255,255,255); font-family:Calibri,Helvetica,sans-serif">early
thinking on </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec%2Fpull%2F23&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C3a64af5de9524b4ea87b08d8fed02d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539517352100649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5WdZrafx04rjXsviI0kjCPQgYQ5VkrLw44anagSsI%2Bk%3D&reserved=0" originalsrc="https://github.com/awoie/vp-token-spec/pull/23" shash="slR+2tr9y6aJEdu/LUYUMgBi4T2gXIOHcIwF8ahdUe0XMWm/0t9BbsBT8P7PtPpsbPgr+OoBixySZYgAq/WsIM+GmSeTQ6Vbv2TvjuT951n8knwuyPrMNM23theAULraT9DkSqEx5VwmD2hXVsMqMX/eWmdg6Bfcf3OHp49weGY=" style="margin:0px; font-size:12pt; background-color:rgb(255,255,255)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">using
aggregated/distributed claims for VCs/VPs</span></a><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span><span style="margin:0px; background-color:rgb(255,255,255); display:inline!important; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">(presentation
slides sent in a separate email)</span><span style="margin:0px; background-color:rgb(255,255,255); display:inline!important"><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">: </span></li><ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">Had a discussion with Mike, Kim, Oliver and Kristina on the specification how to request and convey VC objects (VCOs - includes both VC and
VP) in OIDC</span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">VCOs can come from wherever - ID Token and UserInfo endpoint,etc.</span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)"><b>Requests are controlled by the claims parameters,</b></span><span style="margin:0px; font-size:12pt; font-family:calibri,arial,helvetica,sans-serif; background-color:rgba(0,0,0,0)"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">not
to overload or invent new response types</span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">initial thinking was to have a separate artfact VP token, to compartmentalize different kind of tokens to prevent processing issues especially
with JWT and JSON-LD. </span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">There was also an idea to to use ID Token as VP, but they have different processing rules.</span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">Current option is JWT claims that are arrays and can provision more than one VCO.</span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)"><b>Torsten showed the examples of how vp_jwt and vp_ldp will be embedded in the ID token.</b></span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)"><b>Torsten also showed how aggregated and distributed claims syntax can be used to return VCOs</b></span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">,
using the dictionary that maps to the source</span></li></ul>
<li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tony said that there is a need for a userinfo endpoint support in SIOP.</span></li><li><span style="margin:0px; font-family:Calibri,Helvetica,sans-serif; font-size:12pt">Tom said that there is no use-cases where V</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">C is sent back directly, without being
included in a VP.</span></li><ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Kristina and Torsten agreed, and said it would be clearer once we have more implementation experience.</span></li></ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tony clarified the difference between vc-data-model defined vc vp claims and new claim names used in these slides.</span></li><ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tobias, DW, Mike and Kristina clarified that vp_ldp proof is a container that includes entire VCO and is independent of</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; display:inline!important"> vc
vp claims defined in </span><span style="margin:0px; display:inline!important"><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; display:inline!important">vc-data-model that are used inside the VCO to contain @context, type,
etc. </span></span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Note from Kristina: vc-data-model spec language is one of the reasons of the confu</span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">sion because </span><code style="color:rgb(200,53,0); font-family:Menlo,Consolas,"DejaVu Sans Mono",Monaco,monospace; font-size:0.9em; orphans:3; widows:3; break-before:avoid"><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; color:rgb(0,0,0)">vp
claims is defined as t</span></code><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">he object that "contains the</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span><a href="https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials" class="x_internalDFN" style="margin:0px; border-width:0px 0px 1px; border-bottom-style:solid; border-bottom-color:rgb(153,153,204); font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif"><span style="margin:0px; font-family:Calibri,Helvetica,sans-serif; font-size:12pt">verifiable
presentation</span></a><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">according to this specification", but in the description above
the definition it says that vp claim only "</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">contains those parts of the standard</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span><a href="https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations" class="x_internalDFN" style="margin:0px; border-width:0px 0px 1px; border-bottom-style:solid; border-bottom-color:rgb(153,153,204); font-size:medium; font-family:sans-serif"><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">verifiable
presentations</span></a><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">where no explicit encoding rules for JWT exist" and the examples
follow the description and only VP specific claims (@context, type, etc.) are included in vp claim.</span><br>
</li></ul>
<li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">There was a discussion in</span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">the</span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">chat
in favor of a </span><span lang="EN-US" style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">separate token approace that lives separate from the OIDC claims and contexts. Justin wrote that the ID Token
should be about the authentication event, more than anything </span><span style="margin:0px; font-size:12pt; font-family:calibri,arial,helvetica,sans-serif; background-color:rgba(0,0,0,0)"></span></li><ul>
<li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span lang="EN-US" style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; background-color:rgba(0,0,0,0)">Mike said that the problem with the separate token approach is it probably
means you're inventing new response type values, which isn't an extension point that most of the existing OAuth and OIDC libraries actually have, Whereas all the libraries enable extensions via adding claims - it's a more straightforward way of integration.</span></li><li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Vittorio said that</span><b><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></b><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"><b>proposed
new claim is not the same as any other new claim.</b></span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">If the entire reason you are asking for an ID
token is to get that claim, that's changing the semantics - you are loading an existing primitive for a different out come. </span></li><li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">In that case, re-using existing logic may be disastrous since something that looks like an old stuff actually has different semantics.
He said he is worried about the code that is being used already, that now can parse new artifacts and draw conclusions that are not what we wanted to do to draw.</span></li><li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Justin said that</span><b><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></b><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"><b>new
response_type may not be required.</b></span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> The utility of the response type is to allow clients to signal that they're requesting the different parts of the response separately from
each other and in specific combinations. Including VCs in OIDC is different - it is specifically additive and can be defined as being returned in a specific slot. we are going towards claims query language.</span></li><li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">it's just another data artifact that, if we don't want to, or need to get overly specific about exactly how, and when we want to
give clients, options, about how and where it comes back, then we don't have to.</span></li><li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Torsten asked if it would make sense for a client to ask for a set of claims and do not care whether they can be provided as an
ID token or as VCO.</span></li><li style="font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Mike said that the</span><b><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></b><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"><b>more
choices you give implementations, the less interoperable they're going to be</b></span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">. Standards is exactly the process of making choices so that people interoperate. which is why existing
mechanisms should be used.</span></li></ul>
<li style="font-family:Calibri,Arial,Helvetica,sans-serif"><b><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Currently there are three options - separate tokens, credential sources (library), and custom claim names. </span><span style="margin:0px; background-color:rgb(255,255,255); display:inline!important; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">The
group agreed to take a deeper look at each and</span><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> continue the conversation on the ML, IIW and future calls.</span></b><br>
</li></ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Update on Portable Identifiers draft (if any)</span></li><ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tobias said that he added use-cases and asked for feedback: </span><span style="margin:0px; font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif"><a href="https://mattrglobal.github.io/oidc-portable-identities/#name-usecases" style="margin:0px"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">https://mattrglobal.github.io/oidc-portable-identities/#name-usecases</span></a></span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></li><li><span style="margin:0px; font-family:Calibri,Helvetica,sans-serif; font-size:12pt">It is an alternative type of subject identifier. Currently end user subject identifier is a product of hte provider, the iss claim and the subject. cryptographically verifiable
identifiers would be used to redefine the relationship btw the end user and the provider.</span><br>
</li><li><font color="#000000" face="Calibri, Arial, Helvetica, sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Kristina noted that there are two components emerging - Credential exchange (VCO in OIDC) and authentication using
cryptographically verifiable subject identifiers.</span></font></li></ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1215%2Fsiop-requires-user-consent&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C3a64af5de9524b4ea87b08d8fed02d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539517352110609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yuqUgsUfuKNp28EDDpLjHjAADJfX3LKdVgFvr59AJqg%3D&reserved=0" originalsrc="https://bitbucket.org/openid/connect/issues/1215/siop-requires-user-consent" shash="G7NF+7bNepbszz2Ob/pvzbGSNWrf1w2QpYo9KsOo9zmnEPVWxxEujyNBHHqAi5wYNaLGuAmlXtJkdEj7x14HiU7eawhSQ3a+lZ/ILr1IOKDzdIJYYFUoGS8dTdBbeVL5vifpLFls+L5TCmjcLuU9zm25lrz5euNmD6TdPymKskg=" style="margin:0px"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">#1215
- SIOP requires user consent</span></a></span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1217%2Frequire-jar-in-siop-to-strongly-id-the&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C3a64af5de9524b4ea87b08d8fed02d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539517352100649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dpkiq5sbpg5gsHF%2BSVNQlBq9hSSP3S9HMNYA7gaTyf0%3D&reserved=0" originalsrc="https://bitbucket.org/openid/connect/issues/1217/require-jar-in-siop-to-strongly-id-the" shash="SRk6TP0sq3b8krMCIvX3cIf6GU9+hdiEfesYUnefQ6G49HbEtyfodGEOCd4o+8Df/FQUunja4fRp3vso0rR6QK5muU2fl1GGSYnD+N9y1zOeg1B9ND7eeAgaXrYopf54VHr/FjktcVH1t82zf/+dSrozP3wMWWd71scG7G73A8Q=" style="margin:0px"><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> #1217
- Require JAR in SIOP to strongly ID the Relying Party</span></a><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> - related to the last week's trust model of SIOP discussion</span></span><br>
</li><ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tom Jones said that consent in SIOP has to be required, and suggested using JAR so that the user knows about hte client</span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Torsten asked what would you learn about client by signing request... </span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Jeremie said that in the context of a trust framework, it can make sense because the holder SW can verify against that trust framework. but without a trust framework</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">,
no way for a holder SW to display anything useful to a user. The client might need to present their VP first too.</span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tom said that if TLS is used, domain name with a lock can be showed ot a user even without a framework.</span></li><li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Tom agreed to provide more details to help WG better understand the proposal</span></li></ul>
<li><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">We ran out</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">of
time to discuss</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif"><span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif"> </span></span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">userInfo
in SIOP</span><br>
</li><li>
<div style="margin:0px"></div>
<b><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Next call is </span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; display:inline!important">27th April Atlantic time</span></b><span style="margin:0px; display:inline!important"><b><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; display:inline!important"> </span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; display:inline!important">(7am
PST, 5pm CET, 0AM JST)</span><span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif; display:inline!important"> </span></b></span></li></ul>
<div style="margin:0px; font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif">
<span style="font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Best,</span></div>
<span style="margin:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif">Kristina</span></div>
</div>
</div>
<br>
</div>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div id="x_appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>$B:9=P?M(B:</b> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net> $B$,(B Torsten Lodderstedt via Openid-specs-ab <openid-specs-ab@lists.openid.net> $B$NBeM}$GAw?.(B<br>
<b>$BAw?.F|;~(B:</b> 2021$BG/(B4$B7n(B14$BF|(B 8:01<br>
<b>$B08@h(B:</b> Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net><br>
<b>CC:</b> Torsten Lodderstedt <torsten@lodderstedt.net><br>
<b>$B7oL>(B:</b> [Openid-specs-ab] OpenID Connect for W3C Verifiable Credential Objects</font>
<div> </div>
</div>
<div>
<div class="x_x_BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="x_x_PlainText">Hi all,<br>
<br>
as discussed in the SIOP Special Topic Call, I would like to share with the group the link to our draft and the PRs/branches containing the alternative representations for VPs & VCs.
<br>
<br>
The current revision of the draft can be found at <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468934540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gHC2NGojYFW348vyKQDc%2FzGK48%2B1fSkmzqgWxXgnjec%3D&reserved=0" originalsrc="https://github.com/awoie/vp-token-spec" shash="Zw89t8NPhM44GeenzhYgS2XlQ7AFaEgQoClHMZJPOuT6gj20hCl6G9EUqtxODbrnSxxhZMhzaTrBoetkMOX+XaTgk9nmkdLplbISMSXPfaLHGaJvLij+/CBSFdPrpn6GkyS5fcjlE+DPW5bYXc2ZsHK5Nd+etaSs7d7PqKsqW1c=">
https://github.com/awoie/vp-token-spec</a>. It uses VP Tokens as separate artifact + ID Tokens as Verifiable Presentations.
<br>
<br>
In the context of the ongoing discussion regarding the best way to represent, we created two PRs describing further alternatives in detail:<br>
<br>
- vp_jwt/vp_ldp/vc_jwt/vc_ldp Claims (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec%2Fpull%2F20&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468944494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5KyjcvxVHzFo%2F2CJF4CgCp4wdSNG0qYQi5rcL6Ge1VU%3D&reserved=0" originalsrc="https://github.com/awoie/vp-token-spec/pull/20" shash="kFlG2VFj3ta42nF4ARgZSqskBTpmcZ/f3NLk2Y12R8kwDgf4DaIY7zYPTEjntREoJhhrbXaFYG5XveDm0Fn1p4CduouN/3p5uVAC/Qa5sJN63OPXIxEUXPuTh8sd6vzJ6l4kA1VNJ4aOMRJZtXNYUhYWlCZSalQZB/PNu9c0c6E=">https://github.com/awoie/vp-token-spec/pull/20</a>)<br>
- <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSakurann%2Fvp-token-spec&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468944494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zvTS%2F30zA5vuL0%2BVDlyCuE4ns46R6Bl%2F8YUM4stNhwk%3D&reserved=0" originalsrc="https://github.com/Sakurann/vp-token-spec" shash="ULciuPOzLAdWS6XieHzMOsFMN5DjRT+aB0XcxXhy2/w9/4htwbj4Ewhkyft0IPQnTve4qjBRJVOWOy5ZbHK3RxR//jS/TvddUpNoaIz8hIA3WVdT+lIPjTZKGlUDjRyF7oUAkXzEXih/gCqCmeo/0D20zKQ0yZaohmDqCwyi61I=">
https://github.com/Sakurann/vp-token-spec</a><br>
<br>
- Aggregated & Distributed Claims (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec%2Fpull%2F23&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468954450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vvL%2Fu2DfVYnqmuOf1%2B9VxltnBgmwh7%2FOiA%2BypmQI6OA%3D&reserved=0" originalsrc="https://github.com/awoie/vp-token-spec/pull/23" shash="nk3rg/Sc++MNb4mdEMqjIcNC4GNmrkMHmGb8akiTHA2vPQ1zHlNWKQWXF+mSVe6WBL5CXdSVWiGrSH2GO5JKLMiODx+dbS2ro7e0aCDb0b7vEhso2sy/IZo2/qH7iKBD0j6XSc8GaxMQBzJsLXWXeXVybVxbo6nlh3jxdhLOEAQ=">https://github.com/awoie/vp-token-spec/pull/23</a>)<br>
- <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec%2Ftree%2Fadc&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468954450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8AbJw85Hr%2B3HGu7eCN6ClAKWN%2B1iKF8V78R0kVNfR6s%3D&reserved=0" originalsrc="https://github.com/awoie/vp-token-spec/tree/adc" shash="ZvBP5o2Y4iLR4N3sF9mGDsFJnq5aGBYL7W8t7wv65l87MID8J1z2uLFmHsqrvTbj8Rn9tLiOTFsb1vrESDeT2Ou65Lx75zA0bEG9XfEodX8WZHeGqP2OPYgRifuIVByTvcy5ZoDnw9fVOvnanK4JUCzfDxJURJg09LgBEyY1nPU=">
https://github.com/awoie/vp-token-spec/tree/adc</a><br>
<br>
Look forward to getting your feedback. We would like to work towards the WG adopting our draft.
<br>
<br>
I also added the deck I have shown in the call. <br>
<br>
best regards,<br>
Torsten. <br>
<br>
</div>
</span></font></div>
<div class="x_x_BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="x_x_PlainText">_______________________________________________<br>
Openid-specs-ab mailing list<br>
Openid-specs-ab@lists.openid.net<br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468954450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Tx%2BHW6NdES%2BN6hrigf6ydfSWkqksE6tj6qkFQvomqOo%3D&reserved=0" originalsrc="http://lists.openid.net/mailman/listinfo/openid-specs-ab" shash="KTmfwcho0bmhpbFp9PZ4OpLdi1sZ9INyCGtdk99Cafjdz3uG9lLPMLYVw8bN1IpQNSgX3ksrC+IZNZU5La+XRchMm4H8yN2gn28aFVQOXWABEsQ7QgYEVdAa54XA1tMjcjPJaenP6M2lVUXzVh3luksEdYVheC+5L/dcnB7O/Z4=">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div>
</span></font></div>
</div>
</div>
</div>
</body>
</html>