<div dir="auto">And as the access certificate needs to be one used for Electronic signatures ach to law the good old ETSI EN 319 411 already applcable as a) not exclusively bound to TSP and useable worldwide & b) already contains option to put authorization as "vank", "doctor" in certificate. <div dir="auto"><br></div><div dir="auto">No need for additional attestation.</div><div dir="auto"><br></div><div dir="auto">Beside this Mirko; Your idea would mean that RP goes to ecosystem Party e.g. medical Association to get attestation "doctor", something the registrar proofs without need of EAA. </div><div dir="auto">Practically this means any ecosystems authority issueing such an attestation becomes TSP acc Art. 3 Nr. 16 eIDAS.</div><div dir="auto"><br></div><div dir="auto">So as consultant I have to state: Thanks for the great sales idea. As standardization expert I have to state: reuse ETSI EN 319 411, put value in access certificate - ready.</div><div dir="auto"><br></div><div dir="auto">And be legally compliant. </div><div dir="auto"><br></div><div dir="auto">My Boss would like you</div><div dir="auto"><br></div><div dir="auto">Best</div><div dir="auto">Steffen</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">steffen schwalm <<a href="mailto:schwalm.steffen@googlemail.com">schwalm.steffen@googlemail.com</a>> schrieb am Mi., 23. Apr. 2025, 19:10:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">HI Mirko,<div><br></div><div>additionally explicitly for your the legal sources:<br><br><ul><li>Art 5 "A wallet-relying party shall provide to the relevant register of the Member State where it is established at least the information set out in Annex I. The wallet-relying party shall ensure that all information provided is accurate at the time of registration and when the information is update"</li><ul><li>Annex 1 The name of the wallet-relying party as stated in an official record together with identification data of that official record.<br>2. Where applicable, one or more identifiers of the wallet-relying party, as stated in an official record together with identification data of that official record, expressed as:<br>(a) an Economic Operators Registration and Identification (EORI) number as referred to in Commission Implementing Regulation (EU) No 1352/20131;<br>(b) the registration number as registered in a national business register;<br>(c) a Legal Entity Identifier (LEI) as referred to in Commission Implementing Regulation (EU) No 2022/18602;<br>(d) a VAT registration number;<br>(e) an excise number as specified in Article 2(12) of Council Regulation (EC) No 389/20123;<br>(f) a tax reference number;<br>(g) a European Unique Identifier (EUID) as referred to in Commission Implementing Regulation (EU) 2020/22</li></ul><li>Art. 6 requries that only Art. 5 fulfilled registration RP can start</li><li>REgistration essential for Access Certificate see Art. 7</li></ul><div>your claim "Also your second argument „the registrar knows this“ is legally wrong - as the Registrar has to know if the bank is bank otherwise no registration, no access certificate. As this property is exactly the one needed to proof if certain RP authorized to get certain PID/(Q)EAA - the registrar can add it to the access certificate so that the Root of Trust Approach easily works. </div></div><div><br></div><div>Strongly recommend you proof your approach against the law through a second dedicated lawyer. If it´s possible fine. Best solution would be to aim for change of IA on Art. 5b so that requirement that access certificate is x509 will be changed that it could be also EAA. Would avoid the technical issue of your approach that access certficate = x509 while the evidence for authorization (bank) is attestation.</div><div><br></div><div>Give you the legal session also for free as the legal education of SPRIND is close to my heart. if you don`t aim for eIDAS please mention it in scope. </div><div><br></div><div>Best</div><div>Steffen </div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 23, 2025 at 6:34 PM steffen schwalm <<a href="mailto:schwalm.steffen@googlemail.com" target="_blank" rel="noreferrer">schwalm.steffen@googlemail.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 dir="ltr">Dear Mirko,<div><br></div><div>thanks a lot for your mail,. You seemingly forget the information spread by the chairs so especially Torsten & Kristina but also by you that OIDF works on standards to be used within the eiDAS ecosystem and with this aim is according to its own statements (see chairs) in close collaboration with the European Commission.</div><div><br></div><div>Regarding ETSI: You may forget that its working worldwide as you can see on the website: <a href="https://www.etsi.org/about" target="_blank" rel="noreferrer">https://www.etsi.org/about</a>. Especially the ETSI EN on signatures and certificates are used worldwide.</div><div><br></div><div>Please do not mix up standardization organizations and regulation. The regulation is exactly what we focus on here in the discussion. </div><div><br></div><div>legally and practically you are wrong:<br><br></div><div>1. the IA on Art. 5b eIDAS defines that only following options for disclosur policies on RP Access certificates possible: no one, allow list, Root of Trust</div><div><br></div><div><ul><li>As it´s a final list, there`s no option for your attestation based approach in Europe</li><li>So great that you checked your idea with technical experts - but strongly recommend that you proof it legally in case your idea shall work in Europ</li></ul><div>2. According to Art. 5b eIDAS as well as its IA the Relying Party needs to identify at Registrar. means the Registrar knows if it´s a bank, doctor or SPRIND. So you are legally wrong again. As the Registrar knows and gets the information about kind of Relying Party, the registrar can out this information in the RP Access Certificate. As IA on Art. 5b does not forbid this (in comparison to your idea) - it´s no issue</div></div><div>As the RP already needs to use the Access Certificate your approach only creates additional complexity within the EUDI/eIDAS ecosystem as RP needs Access Certificate (which has to be x509 by law!) + attestations</div><div><br></div><div>However, if OID4VP and your preferred approach on Relying Party Authorization is not aimed for eIDAS ecosystem I strongly recommend to mention this explicitly in the scope of the standard - this would help users & implementers to assess its applicability for the EUDI Wallet.</div><div><br></div><div>3. Your claim "And this is also not the way the European Commission wants to go via forcing QTSPs for everything! Member States that want to use QTSPs can do so, others can avoid it" is misleading. Nobody spoke about using QTSP for this . only to reuse a European Standard for the Access certificate. Maybe you read my mail again</div><div><br></div><div>Recommend you go deeper in the subject how values like "Bank", "doctor" or similar can be added to x509 and easily proven. We already do this with x509 worldwide without the need of an attestation.</div><div><br></div><div>So you are technically wrong again and mix up the subject.</div><div><br></div><div>;Long story short: Within the eIDAS Ecosystem your approach only leads to additional effort and is legally impossible - better unlawful or illegal. If OIDF aims to use OID4VP in its current version for eiDAS Ecosystem strongly recommend to go the step to proof the legal applicability to eIDAS 2.0.</div><div><br></div><div>I offer to explain it to you in personal meeting.<br><br>BTW: I never mentioned that you agreed to my claims but that we discussed it ;-)<br><br>As the approach is illegal I hold up my opposition to move current draft to public review.<br><br>PS: Recommend you read and understand first before you argue and assume about subjects which were not mentioned by anybody in the discussion - or are you the Donald Trump of SPRIND? </div><div><br></div><div>Best</div><div>Steffen </div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 23, 2025 at 1:00 PM Mirko Mollik <<a href="mailto:mirko.mollik@eudi.sprind.org" target="_blank" rel="noreferrer">mirko.mollik@eudi.sprind.org</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>Dear Steffen,<div><br></div><div>Please do not mix up different topics here. You seem to forget that OIDF is building standards that are focused to be used world wide, not with the primary focus like it’s done with ETSI and CEN. I already explained on Tom’s Issue on GitHub that from a European perspective the latest changes in spec are fine to be aligned with the requirements from eIDAS and GDPR. We can implement all requirements for Authentication and Authorization. The approach was already challenged multiple times with security and privacy experts across Europe, and they like the approach.</div><div><br></div><div>Also your second argument „the registrar knows this“, is wrong. It’s not enforced by the implementing acts to handle this and it’s up to the member states how to do this. And this is also not the way the European Commission wants to go via forcing QTSPs for everything! Member States that want to use QTSPs can do so, others can avoid it.</div><div><br></div><div>Long story short: I never agreed with Steffen on his claim and I am open to discuss with others about potential gaps in the protocol that we need to fix in the future.</div><div><br></div><div>#rough consensus</div><div><br></div><div>Cheers</div><div><br></div><div><div>P.S. don’t argue like the person on your mentioned slide pls</div></div><div><br></div><div><div>
<div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div>- <br>Mirko Mollik <br><br>Identity Architect (EUDI-Wallet-Projekt) <a href="mailto:mirko.mollik@eudi.sprind.org" target="_blank" rel="noreferrer">mirko.mollik@eudi.sprind.org</a><br><br>SPRIND GmbH <br><br>BUNDESAGENTUR FÜR SPRUNGINNOVATIONEN <br>FEDERAL AGENCY FOR DISRUPTIVE INNOVATION <br>Lagerhofstraße 4, 04103 Leipzig <br><br><a href="http://www.sprind.org" target="_blank" rel="noreferrer">www.sprind.org</a> <br><br>Geschäftsführung: Berit Dannenberg, Rafael Laguna de la Vera <br>Vorsitzender des Aufsichtsrats: Dr.-Ing. E. h. Peter Leibinger <br>Amtsgericht Leipzig – HRB 36977 <br>USt-ID DE328253854 <br>Disclaimer</div></div>
</div>
<div><br><blockquote type="cite"><div>Am 23.04.2025 um 11:45 schrieb steffen schwalm via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-digital-credentials-protocols@lists.openid.net</a>>:</div><br><div><div dir="ltr">Dear all,<div><br></div><div>as briefly discussed with Mirko: The following approach defined in Slid 12 fpr the document <a href="https://docs.google.com/presentation/d/1s-MM27j4ZxACf0ecuVBGbuj8o4C5kr9g62jXeby0wso/edit?pli=1#slide=id.g3105e024338_0_7" target="_blank" rel="noreferrer">https://docs.google.com/presentation/d/1s-MM27j4ZxACf0ecuVBGbuj8o4C5kr9g62jXeby0wso/edit?pli=1#slide=id.g3105e024338_0_7</a> is IMHO legally wrong acc. to the Implementing Act. The IA defines: no policy, allow list or root of trust not an Attribute based access control.<br><br></div><div>With the background that embedded policies well-known (see signature validation policy), any RP must be listed and identified by Registrar anyway. Means the Registrar already has the identity and the property "bank", "doctor", "Municipality Buxtehude". If this property is written in the Access Certificate it can be proven by the wallet when RP requests PID/EAA data. If the correct property e.g. "Bank" given that request is proven correctly. The Root of Trust would be (QTSP--> QEAA) --> Access Certificate --> Registrar. As those lists already exist e.g.banking supervision authority, Medical Association etc. it seems not comprehensible to create new complexitites especially as the access certificate is already x509. </div><div>This is already possible with existing x509 and reusing the standards like ETSI EN 319 411 family,.</div><div><br></div><div>And before the discussions comes: The issue here is not similar to W3CVCDM that there might be no standard for authorization of RP - we already have them. </div><div><br></div><div>Long Story short: I support Tom and also oppose to move OID4VP to public review.</div><div><br></div><div>Best</div><div>Steffen </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 23, 2025 at 10:26 AM steffen schwalm <<a href="mailto:schwalm.steffen@googlemail.com" target="_blank" rel="noreferrer">schwalm.steffen@googlemail.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 dir="ltr">Joseph:<br><br>As OIDF according to its own statements aims to define specifications in support of EUDI Wallet your statement "
<span style="color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"> given many things are out of scope for OID4VP and defined by local ecosystem requirements/laws" is highly dangerous. If OID4VP aims for EUDI any risk of legal breach as Tom assumes shall be avoided.</span><div><span style="color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br></span></div><div><span style="color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">means: if you believe that "</span><span style="color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">OID4VP can also be used in a way that is compliant with such laws" --> exactly this way shall be defined as the only possible one to be in compliance with GDPR, eIDAS etc. Would be typical approach we know from ETSI, CEN, ISO.</span></div><div><br></div><div>Currently looking at the mails I support Tom in his doubts.<br><br>Beside this I oppose against to bring OID4VP in current version in next step: DCQL only requires to write query per credential format which is weird - in comparison to presentation exchange. Recommend to open the door for presentation exchange as optional possibility.<br><br>Best<br>Steffen</div><div><span style="color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 23, 2025 at 12:39 AM Joseph Heenan via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">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>Hi Tom<div><br></div><div>To repeat what I added to on the issue a few days ago, <a href="https://github.com/openid/OpenID4VP/issues/333#issuecomment-2816774542" target="_blank" rel="noreferrer">https://github.com/openid/OpenID4VP/issues/333#issuecomment-2816774542</a> :</div><div><br></div><div><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">I've read back through this issue. There seem to be a number of questions I've asked Tom that I've not obviously got answers to, such as "To try and clarify: you agree that user consent is happening, your doubt is to whether the consent is sufficiently informed?". Being unable to narrow down exactly what Tom believes the problem is or isn't is significantly hampering figuring out if there's a problem that needs to be solve in the specification or not.</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br></p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">I think we've replied to every point Tom has raised, with the possible exception of not fully replying to this one:</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br></p><blockquote style="box-sizing:border-box;margin-top:0px;margin-right:0px;margin-left:0px;padding:0px 1em;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><p dir="auto" style="box-sizing:border-box;margin-top:0px">Digital identity wallets must ascertain the identity of Verifiers and determine whether these Verifiers possess the necessary authorisation or obligation to request Verifiable Credentials (VCs) or claims.</p><div style="box-sizing:border-box;margin-top:0px;margin-bottom:0px">I don't see how OID4VP provides that - all i see is a URL that the user must decide whether to trust.</div></blockquote><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br></p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">I already explained that OID4VP provides for this via <a href="https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-client-identifier-prefix-an" rel="nofollow noreferrer" style="box-sizing:border-box;color:rgb(31,35,40)" target="_blank">https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-client-identifier-prefix-an</a> (for example, x509_san_dns defined there does not require the user to declare whether they trust a URL or not, it can be PKI certs that assert a trusted name for the verifier etc) but it's perhaps also worth sharing that the "possess the necessary authorisation or obligation to request Verifiable Credentials (VCs) or claims." part is being solved in an EU specific way, there was a presentation about this at the recent IIW:</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><a href="https://docs.google.com/presentation/d/1s-MM27j4ZxACf0ecuVBGbuj8o4C5kr9g62jXeby0wso/edit#slide=id.g34994030800_0_349" rel="nofollow noreferrer" style="box-sizing:border-box;color:rgb(31,35,40)" target="_blank">https://docs.google.com/presentation/d/1s-MM27j4ZxACf0ecuVBGbuj8o4C5kr9g62jXeby0wso/edit#slide=id.g34994030800_0_349</a></p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br></p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">My understanding of the current situation:</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br></p><ol dir="auto" style="box-sizing:border-box;padding-left:2em;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><li style="box-sizing:border-box">Tom believes that OID4VP can be used in ways that are not compliant with laws such as EU GDPR / EUDI wallet regulations (a point that I believe there is agreement on, given many things are out of scope for OID4VP and defined by local ecosystem requirements/laws)</li><li style="box-sizing:border-box;margin-top:0.25em">Tom doesn't like the way verifier authentication was done at the California hackathon.</li><li style="box-sizing:border-box;margin-top:0.25em">Everyone (except for Tom?) seems to believes OID4VP can also be used in a way that is compliant with such laws</li></ol><div style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px;margin-bottom:0px"><br></div><div style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px;margin-bottom:0px">Is this a correct summary?</div><div><br></div><div>(Mirko also added a comment with more detail on how this would work in </div><div><br></div><div>Thanks</div><div><br></div><div>Joseph</div><div><br></div><div><br><blockquote type="cite"><div>On 18 Apr 2025, at 11:35, Tom Jones <<a href="mailto:thomasclinganjones@gmail.com" target="_blank" rel="noreferrer">thomasclinganjones@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>i do not believe the spec is ready.</div><div>see <a href="https://github.com/openid/OpenID4VP/issues/333" target="_blank" rel="noreferrer">https://github.com/openid/OpenID4VP/issues/333</a></div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><font face="-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" color="#38761d"><span style="font-size:14px;background-color:rgb(242,242,242)">Peace ..tom jones</span></font></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 12, 2025 at 2:12 PM Joseph Heenan via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">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><div><div>Dear DCP Working Group Members,</div><div><br></div><div>As discussed on the Friday working group call we would like to get WG consensus that the OpenID4VP draft is ready to start the final specification approval process.</div><div><br></div><div>Please respond to this email within the next 7 days, by end of Sunday 20th April, whether you believe the draft should proceed to the public review or not. </div><div> </div><div>The OpenID4VP document to be reviewed can be found here: <a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0-26.html" target="_blank" rel="noreferrer">https://openid.net/specs/openid-4-verifiable-presentations-1_0-26.html</a></div><div><br></div><div>There are a couple of normative changes that we discussed during the working group meeting on Friday to work on during working group last call:</div><div><br></div><div>1. revamp vp formats: <a href="https://github.com/openid/OpenID4VP/pull/500" target="_blank" rel="noreferrer">https://github.com/openid/OpenID4VP/pull/500</a></div><div><br></div><div>2. Specifies value matching for mdocs via a reference to cbor-to-json: <a href="https://github.com/openid/OpenID4VP/pull/538" target="_blank" rel="noreferrer">https://github.com/openid/OpenID4VP/pull/538</a></div><div><br></div><div>3. Remove references to ISO 18013-7 to avoid confusion due to it using OID4VP ID2: <a href="https://github.com/openid/OpenID4VP/issues/519" target="_blank" rel="noreferrer">https://github.com/openid/OpenID4VP/issues/519</a></div><div><br></div><div>4. Remove anoncreds for now (hoping to add it back in 1.1) due to lack of implementation experience with DCQL etc: <a href="https://github.com/openid/OpenID4VP/pull/539" target="_blank" rel="noreferrer">https://github.com/openid/OpenID4VP/pull/539</a></div><div><br></div><div>We’d also expect some editorial/non-normative changes during WGLC.</div><div><br></div><div>We also discussed scheduling a meeting to talk about the sd-jwt vcld pr: <a href="https://github.com/openid/OpenID4VP/pull/459" target="_blank" rel="noreferrer">https://github.com/openid/OpenID4VP/pull/459</a> (a separate email about this will follow shortly.)</div><div><br></div><div>If there are other topics working group members think need to be handled before the specification moves to final please reply to this email with details.</div><div><br></div><div>This is very much just a step on the journey, and it is likely that comments will arrive during the 60 day review period that the working group chooses to fix before the voting period starts.</div><div><br></div><div>The details of the specification approval process can be found here: <a href="https://openid.net/wg/resources/approving-specifications/" target="_blank" rel="noreferrer">https://openid.net/wg/resources/approving-specifications/</a>.</div><div><br></div><div>This email is about the first bullet point on this list "Obtain working group consensus to propose foundation-wide approval of the draft specification", which is often called Working Group Last Call (WGLC).</div><div>The following steps are to start a 60-day Foundation-wide review, followed by the 7 day voting period (the poll itself will open 7 days before the end of the Foundation-wide review ends).</div><div><br></div><div>Kindest Regards,</div><div>Editors & Chairs</div><div><br></div></div></div>-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">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>
</div></blockquote></div><br></div></div>-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">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>
-- <br>Openid-specs-digital-credentials-protocols mailing list<br><a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">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" rel="noreferrer">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br></div></blockquote></div><br></div></div></blockquote></div>
</blockquote></div>
</blockquote></div>