<div dir="ltr">to be specific about what Jo said.<div><br></div><div>It cannot be assumed that the subject is the entity that is communicating information about itself. That is the killer to most of the id stds to date.<br><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>..tom</div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 19, 2023 at 9:45 AM Jo Spencer via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)">Hi Joseph,</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)">You're quite right, a protocol is just that, a protocol. The challenge that protocol only mechanisms have is that they can struggle to represent data from third parties as part of the protocol without endpoint / identity correlation. The beauty of the W3C-based decentralised identity model is that credentials can be shared from different issuers in a combined presentation from the same endpoint without that correlation. With guardianship or delegated scenarios, this is particularly important. </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)">My challenge to the OpenID protocols is to demonstrate how the same features of truly decentralised (Autonomic IDentifier (AID) based) interaction protocols could be incorporated. If you want to know more about AIDs and non-correlatable protocols, you could have a look at KERI - <a href="https://keri.one/keri-resources/" target="_blank">https://keri.one/keri-resources/</a>.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)">Cheers, Jo</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)"> </div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><table width="630" cellspacing="2" cellpadding="2" border="0" style="color:rgb(136,136,136)"><tbody><tr><td width="600" valign="top"><div><font size="2"><b><font face="Verdana" color="#666666">Jo Spencer</font></b></font></div><div><font face="verdana, sans-serif" color="#666666"><font size="2">Co-Founder | Digital Trust Evangelist | <b>Sezoo</b></font><font size="2"><br></font></font></div><div><font face="verdana, sans-serif" color="#666666"><font size="2">Partner | Payments |</font><font size="2"> Banking |</font> Architecture | <b>460degrees</b></font></div><div><font size="2" color="#3d3d3d"><br></font><font size="2" face="Verdana" color="#000000">M:</font><font size="2" face="Verdana"> <font color="#0b5394">+61 (0) 433 774 729</font></font></div><div><font size="2" face="Verdana" color="#3d3d3d">E: <a href="mailto:jo@sezoo.digital" style="color:rgb(17,85,204)" target="_blank">jo@sezoo.digital</a></font><font size="2" color="#3d3d3d"><br></font></div><div><font size="2" color="#3d3d3d"><font face="Verdana">L: <a href="https://www.linkedin.com/in/jospencer-1pg/" style="color:rgb(17,85,204)" target="_blank">https://www.linkedin.com/in/jospencer-1pg/</a></font><br><font face="Verdana">T: <a href="https://twitter.com/spencerjed" style="color:rgb(17,85,204)" target="_blank">https://twitter.com/spencerjed</a></font></font><br></div></td></tr></tbody></table><img src="https://ci3.googleusercontent.com/mail-sig/AIorK4zyqQOWd8gSpsOrrNQX1snRdGuO7PQrEWP87Dcfxi3XkvLDX0pn5VC55P1wwXJhkNB9lI6iCbs"><br><table width="630" cellspacing="2" cellpadding="2" border="0" style="color:rgb(136,136,136)"><tbody><tr><td valign="top"><div style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><div><font size="1" color="#666666" face="verdana, sans-serif">Sezoo</font><font size="1" face="Verdana" color="#666666"> acknowledges the Traditional Owners of the country throughout Australia and their continuing connection to land, sea and community. We pay our respects to them, their cultures and to Elders past, present and emerging<font face="verdana, sans-serif">.</font></font><div style="color:rgb(102,102,102);font-family:verdana,sans-serif"></div></div><div style="font-family:verdana,sans-serif;color:rgb(102,102,102)"><div></div></div></div></td></tr></tbody></table><br></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Sept 2023 at 00:44, Joseph Heenan <<a href="mailto:joseph@authlete.com" target="_blank">joseph@authlete.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi Jo<div><br></div><div>Thanks for sharing all these documents. I’ve done by best to read them but may have missed things.</div><div><br></div><div>For clarity, the OpenID for Verifiable Presentations and OpenID for Verifiable Credential Issuance only define the protocol mechanisms for transferring credentials from an issuer to a wallet and from a wallet to a verifier. They do not concern themselves with contents or format of the digital credential.</div><div><br></div><div><div>Further up the thread we identified some terminology that could be cleaned up to make things clearer.</div><div><br></div><div>Other than that, it is not clear to me what more the two protocols named above could do. If you have a concrete case where these protocols don’t allow sufficient information to be transferred from the wallet to the issuer or from the wallet to the verifier it would be helpful if you could share that please.</div><div><br></div><div>Thanks</div><div><br></div><div>Joseph</div><div><br></div><div><br><blockquote type="cite"><div>On 17 Sep 2023, at 12:23, Jo Spencer via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)">Hi Tom and Team,</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)">I think you're spot on, Tom. "Guardianship" is a topic that John Phillips and I [Sezoo, based in Melbourne, Australia] have been working on, within the W3C VC-based environment for some time. The W3C VC data model caters to the subject and holder being different, very well. </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)">It's been a particular "passion" capability of ours that digital interactions can forget (probably because it's typically quite complex for 2-party digital interactions). We believe that delegation or guardianship is a critical feature of a trusted interaction mechanism (and protocol), and has to be standardised. Whilst we focused on guardianship, delegation, support or ownership are similar relationship based considerations that should also be able to be supported in a consistent model.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(102,102,102)"><div class="gmail_default"><font face="verdana, sans-serif" color="#666666">Our work and experience on providing verifiable evidence of guardianship rights and duties and supported access to online content started in 2019 when John and I were co-chairs on the Sovrin Guardianship Working Group for the development of an Implementation Guide and Requirements document for Guardianship using W3C Verifiable Credentials. The results published in 2021 can be found here:</font></div><div class="gmail_default"><font face="verdana, sans-serif" color="#666666"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif" color="#666666">Implementation Guide: <a href="https://drive.google.com/file/d/1vBePVx8n3MRDWcePkwVDya9ab4BHEyU_/view?usp=sharing" target="_blank">https://drive.google.com/file/d/1vBePVx8n3MRDWcePkwVDya9ab4BHEyU_/view?usp=sharing</a></font></div><div class="gmail_default"><font face="verdana, sans-serif" color="#666666">Technical Requirements: <a href="https://drive.google.com/file/d/1M21PznPAd0H6z1t4ODl-jiEoXZjEhwcb/view?usp=sharing" target="_blank">https://drive.google.com/file/d/1M21PznPAd0H6z1t4ODl-jiEoXZjEhwcb/view?usp=sharing</a></font></div><div class="gmail_default"><font face="verdana, sans-serif" color="#666666"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif" color="#666666">These links and the introduction/explanation can be found here: <a href="https://sovrin.org/a-deeper-understanding-of-implementing-guardianship/" target="_blank">https://sovrin.org/a-deeper-understanding-of-implementing-guardianship/</a></font></div><div class="gmail_default"><font face="verdana, sans-serif" color="#666666"><br></font></div><div class="gmail_default">As a part of these initiatives, a mental model for guardianship was developed with collaboration with TNO in NL and published under the ESSIFLabs initiative: <a href="https://essif-lab.github.io/framework/docs/terms/pattern-guardianship/" target="_blank">https://essif-lab.github.io/framework/docs/terms/pattern-guardianship/</a>. </div><div class="gmail_default"><br></div><div class="gmail_default">More recently, we've supported the update of the Sovrin Whitepaper on Guardianship - <a href="https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper-V2.0.pdf" target="_blank">https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper-V2.0.pdf</a> - which may be a very good starting document for those that are interested.</div><div class="gmail_default"><font face="verdana, sans-serif" color="#666666"><br></font></div><div class="gmail_default"></div><div class="gmail_default">We developed a Guardianship addendum for the <a href="https://www.goodhealthpass.org/blueprint" target="_blank">Good Health Pass Collaborative Blueprint</a> which considered the challenges of supported travel, made more important during the Covid pandemic. The realisation during that activity was that guardianship and supported mechanisms are often informal and based on social expectations, rather than digital credentials. Enabling supported scenarios using digital credentials into the whole process of travel was a significant challenge and probably more than the GHPC could influence. </div><div class="gmail_default"><br></div><div class="gmail_default">John Phillips and I have published a number of further papers and work on this topic, all of which are available on our website (<a href="https://www.sezoo.digital/resources/" target="_blank">https://www.sezoo.digital/resources/</a>) and our LinkedIn profiles (<a href="https://www.linkedin.com/in/11dot2/recent-activity/articles/" target="_blank">https://www.linkedin.com/in/11dot2/recent-activity/articles/</a> and <a href="https://www.linkedin.com/in/jospencer-1pg/recent-activity/articles/" target="_blank">https://www.linkedin.com/in/jospencer-1pg/recent-activity/articles/</a>)<br></div><div class="gmail_default"><font face="verdana, sans-serif" color="#666666"><br></font></div><div class="gmail_default">It's critical that any interaction protocol supports delegation, support or guardianship and clearly articulates the difference between the Holder and Subject. Impersonation has to be avoided as this is the antithesis of trusted digital interactions. The combined presentation of credentials from multiple sources (e.g. a guardianship VC from a government entity and other credentials from other service providers) would appear to be central to these types of solutions. We too have been concerned that the OIDC4VP protocols are deficient in this, but we'd be keen to learn more from those who are closer to the details. But we are very keen to promote these considerations in solution design activities. </div><div class="gmail_default"><br></div><div class="gmail_default">Of course, I'd be happy to talk about this topic in the group (if this can be possible in an Australian-friendly timeslot), or directly. </div><div class="gmail_default"><br></div><div class="gmail_default">Cheers, Jo</div></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><table width="630" cellspacing="2" cellpadding="2" border="0" style="color:rgb(136,136,136)"><tbody><tr><td width="600" valign="top"><div><font size="2"><b><font face="Verdana" color="#666666">Jo Spencer</font></b></font></div><div><font face="verdana, sans-serif" color="#666666"><font size="2">Co-Founder | Digital Trust Evangelist | <b>Sezoo</b></font><font size="2"><br></font></font></div><div><font face="verdana, sans-serif" color="#666666"><font size="2">Partner | Payments |</font><font size="2"> Banking |</font> Architecture | <b>460degrees</b></font></div><div><font size="2" color="#3d3d3d"><br></font><font size="2" face="Verdana">M:</font><font size="2" face="Verdana"> <font color="#0b5394">+61 (0) 433 774 729</font></font></div><div><font size="2" face="Verdana" color="#3d3d3d">E: <a href="mailto:jo@sezoo.digital" style="color:rgb(17,85,204)" target="_blank">jo@sezoo.digital</a></font><font size="2" color="#3d3d3d"><br></font></div><div><font size="2" color="#3d3d3d"><font face="Verdana">L: <a href="https://www.linkedin.com/in/jospencer-1pg/" style="color:rgb(17,85,204)" target="_blank">https://www.linkedin.com/in/jospencer-1pg/</a></font><br><font face="Verdana">T: <a href="https://twitter.com/spencerjed" style="color:rgb(17,85,204)" target="_blank">https://twitter.com/spencerjed</a></font></font><br></div></td></tr></tbody></table><img src="https://ci3.googleusercontent.com/mail-sig/AIorK4zyqQOWd8gSpsOrrNQX1snRdGuO7PQrEWP87Dcfxi3XkvLDX0pn5VC55P1wwXJhkNB9lI6iCbs"><br><table width="630" cellspacing="2" cellpadding="2" border="0" style="color:rgb(136,136,136)"><tbody><tr><td valign="top"><div style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><div><font size="1" color="#666666" face="verdana, sans-serif">Sezoo</font><font size="1" face="Verdana" color="#666666"> acknowledges the Traditional Owners of the country throughout Australia and their continuing connection to land, sea and community. We pay our respects to them, their cultures and to Elders past, present and emerging<font face="verdana, sans-serif">.</font></font><div style="color:rgb(102,102,102);font-family:verdana,sans-serif"></div></div><div style="font-family:verdana,sans-serif;color:rgb(102,102,102)"><div></div></div></div></td></tr></tbody></table><br></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 15 Sept 2023 at 04:38, Tom Jones via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><br><span style="color:rgb(240,246,252);font-family:-apple-system,blinkmacsystemfont,"segoe ui","noto sans",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji";font-size:16px;background-color:rgb(22,27,34)">All parties communicate with each other using a set of protocols, or just "protocol" in the following. In the case of OpenID4VP, the protocols are OpenID for Verifiable Credential Issuance [@!OpenID.VCI] and OpenID for Verifiable Presentations [@!OpenID.VP], with an optional use of SIOP v2 [@!OpenID.SIOPv2].</span><br><div>thx ..Tom (mobile)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 14, 2023, 4:17 AM David Chadwick <<a href="mailto:d.w.chadwick@truetrust.co.uk" target="_blank">d.w.chadwick@truetrust.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><p>Hi Tom</p><p>if you read my proposed text I think it caters for the use cases
you are suggesting. If it does not, can you say why not please<br>
</p><p>thanks</p><p>David<br>
</p>
<div>On 14/09/2023 05:35, Tom Jones wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">you guys are missing the point - i guess i was not
clear.
<div><br>
</div>
<div>The current CBP-ONE app is used at the border of the US to
schedule sessions to acquire asylum. Similarly the child
trying to get access to the US may need creds. These children
are the subjects of credential. They do not hold
smartphones which are held by (for example) their father as
guardian. In the US 51 million people do not have smart phones
but may need digital creds for one reason or another. I
suspect that in many countries the numbers are even more dire.</div>
<div><br>
</div>
<div>If the wallet cannot handle the case where the subject is
not the holder, then it should not be considered adequate to
hold government creds because of the many eligible people \who
cannot be accommodated.</div>
<div><br>
</div>
<div>Somehow this spec (and the rest of the VC specs) needs to
address the problem where the holder and the subject are not
the same person.</div>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div><span style="background-color:rgb(242,242,242);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap"> </span>..tom</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 13, 2023 at
3:32 AM David Chadwick via
Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" rel="noreferrer" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><p><br>
</p>
<div>On 12/09/2023 20:53, Joseph Heenan via
Openid-specs-digital-credentials-protocols wrote:<br>
</div>
<blockquote type="cite"> Hi Tom
<div><br>
</div>
<div>Focussing on this particular document, is your
concern resolved if sentences like this:</div>
<div><br>
</div>
<div>"Identity of Holder: A Verifier can trust that the
party presenting the claims in a session with the
Verifier is (controlled by) the subject of the claims.”</div>
<div><br>
</div>
<div>(From <a href="https://github.com/vcstuff/oid4vc-security-and-trust/blob/main/draft-oid4vc-security-and-trust.md#trust-in-the-issuer-holder-verifier-model" rel="noreferrer" target="_blank">https://github.com/vcstuff/oid4vc-security-and-trust/blob/main/draft-oid4vc-security-and-trust.md#trust-in-the-issuer-holder-verifier-model</a>)</div>
<div><br>
</div>
<div>are replaced with something like this:</div>
<div><br>
</div>
<div>
<div>"Identity of Holder: A
Verifier can trust that the party presenting the
claims in a session with the Verifier is (controlled
by) the party that the credential was intended to be
issued to.”</div>
</div>
</blockquote><p>I don't think the above is precise enough, since the
credential could have been passed from the first holder to
the second holder and then to the verifier. Therefore I
propose</p><p>"Identity of Holder: A Verifier can trust that the party
presenting the claims in a session with the Verifier is
the party who is authorised to hold the credential (from
the Verifier's perspective).”</p><p>The text in parentheses is important for at least the
following reasons</p><p>a) the credential could be a bearer credential<br>
</p><p>b) the verifier may be willing to completely ignore who
the issuer intended the credential to be presented by and
therefore will allow anyone to present it, e.g. because
the verifier gains a benefit from entering into a session
with the holder.</p><p>We have real life examples the above in the physical
world.<br>
</p><p>Kind regards</p><p>David<br>
</p>
<blockquote type="cite">
<div><br>
</div>
<div>?<br>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Joseph</div>
<div><br>
<blockquote type="cite">
<div>On 12 Sep 2023, at 16:06, Tom Jones via
Openid-specs-digital-credentials-protocols <a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" rel="noreferrer" target="_blank"><openid-specs-digital-credentials-protocols@lists.openid.net></a>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>One major problem with the OAuth
model and this contribution is the
conflation of the subject and the
holder.</div>
<div>To be inclusive these two roles may
be entirely different entities.</div>
<div>It seems to be that this conflation
must be excised if OAuth is to be
acceptected as the digital credential
model to be used for government supplied
rights and privileges.</div>
<div><br>
</div>
<div>..tom</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Sep
11, 2023 at 8:14 AM Daniel Fett via
Openid-specs-digital-credentials-protocols
<<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" rel="noreferrer" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><p>Hi all,</p><p>I'd like to contribute the "Security and
Trust" document to the DCP WG: <a href="https://github.com/vcstuff/oid4vc-security-and-trust" rel="noreferrer" target="_blank">https://github.com/vcstuff/oid4vc-security-and-trust</a></p><p>It has been discussed earlier, but had no
official status so far. <br>
</p><p>-Daniel<br>
</p>
</div>
-- <br>
Openid-specs-digital-credentials-protocols
mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote>
</div>
-- <br>
Openid-specs-digital-credentials-protocols mailing
list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
</blockquote>
</div>
-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>
-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote></div>
-- <br>Openid-specs-digital-credentials-protocols mailing list<br><a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br><a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br></div></blockquote></div><br></div></div></blockquote></div>
-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote></div>