[{"author": "Carsten Bormann", "text": "<p><a href=\"https://notes.ietf.org/notes-ietf-interim-2024-oauth-07-oauth\">https://notes.ietf.org/notes-ietf-interim-2024-oauth-07-oauth</a></p>", "time": "2024-12-09T17:02:52Z"}, {"author": "Tim Cappalli", "text": "<p>do you have your charred shoes on Brian?</p>", "time": "2024-12-09T17:08:18Z"}, {"author": "Richard Barnes", "text": "<p>i agree with Dr. Fett re agenda slides</p>", "time": "2024-12-09T17:09:29Z"}, {"author": "Daniel Fett", "text": "<p>I agree with Richard on him agreeing with me</p>", "time": "2024-12-09T17:10:27Z"}, {"author": "Watson Ladd", "text": "<p>dc? I think I'm fine to not know honestly</p>", "time": "2024-12-09T17:10:43Z"}, {"author": "Richard Barnes", "text": "<p>USG-endorsed credentials</p>", "time": "2024-12-09T17:11:01Z"}, {"author": "Carsten Bormann", "text": "<p>If you don't know why you have agenda slides, don't use them</p>", "time": "2024-12-09T17:11:05Z"}, {"author": "Michael Jones", "text": "<p>I'm honored for being poked fun at by Brian in his presentation</p>", "time": "2024-12-09T17:11:31Z"}, {"author": "Deb Cooley", "text": "<p>not District of Columbia, @richard</p>", "time": "2024-12-09T17:11:33Z"}, {"author": "Richard Barnes", "text": "<p>Direct Current Credentials</p>", "time": "2024-12-09T17:11:44Z"}, {"author": "Deb Cooley", "text": "<p>I personally like Deb Cooley credentials.</p>", "time": "2024-12-09T17:12:15Z"}, {"author": "Richard Barnes", "text": "<p><span aria-label=\"sunglasses\" class=\"emoji emoji-1f60e\" role=\"img\" title=\"sunglasses\">:sunglasses:</span><span aria-label=\"+1\" class=\"emoji emoji-1f44d\" role=\"img\" title=\"+1\">:+1:</span></p>", "time": "2024-12-09T17:12:42Z"}, {"author": "Watson Ladd", "text": "<p>I have a lot of concerns about the security issues that some of these changes introduce, and its not clear they have been thought about at all. Not related to selective disclosure at all.</p>", "time": "2024-12-09T17:13:05Z"}, {"author": "Richard Barnes", "text": "<p>@Watson - Which changes do you mean?</p>", "time": "2024-12-09T17:13:19Z"}, {"author": "Watson Ladd", "text": "<p>how does x509 and verifier metadata interact? if I trust <a href=\"http://example.com\">example.com</a>, but expect x5c, can someone registering it later end up getting more things signed via the metadata</p>", "time": "2024-12-09T17:13:58Z"}, {"author": "Watson Ladd", "text": "<p>also the incluson of SVGs: such  an easy way for a legit issuer to imitate another</p>", "time": "2024-12-09T17:14:15Z"}, {"author": "Watson Ladd", "text": "<p>i might be verifing a bunch of corporate ids so need open things, but now you make one look like a drivers license via the logo and kaboom</p>", "time": "2024-12-09T17:14:49Z"}, {"author": "Watson Ladd", "text": "<p>basically we're speedrunning the last 10 years of browser security</p>", "time": "2024-12-09T17:15:13Z"}, {"author": "Richard Barnes", "text": "<p>yeah, that does seem concerning.  also SVG does not seem like Minimum Viable here</p>", "time": "2024-12-09T17:15:18Z"}, {"author": "Oliver Terbu", "text": "<p>@Watson: this is a valid concern and we have to adjust the language accordingly.</p>", "time": "2024-12-09T17:16:52Z"}, {"author": "Richard Barnes", "text": "<p>SD is in fact addictive</p>", "time": "2024-12-09T17:17:33Z"}, {"author": "Kristina Yasuda", "text": "<p>there are concerns but let's be careful not to try solve all of the trust model open questions/issues of the wallet model in credential format spec</p>", "time": "2024-12-09T17:20:53Z"}, {"author": "Richard Barnes", "text": "<p>+1 Kristina.  One can always add validation methods, so getting one in place that gets something going seems like the most important thing</p>", "time": "2024-12-09T17:21:35Z"}, {"author": "Watson Ladd", "text": "<p>one can't add validation methods, unless we redefine issuer to be issuer+validation methods</p>", "time": "2024-12-09T17:21:56Z"}, {"author": "Richard Barnes", "text": "<p>in which case, the important thing is to make sure the right extensibility bits are in place</p>", "time": "2024-12-09T17:23:05Z"}, {"author": "Daniel Fett", "text": "<p>Issue on SVGs, or actually, can we trust metadata? <a href=\"https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/282\">https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/282</a></p>", "time": "2024-12-09T17:23:29Z"}, {"author": "Richard Barnes", "text": "<p>so just to be clear: this is about DIDs to identify issuers, right?  not subjects</p>", "time": "2024-12-09T17:23:35Z"}, {"author": "Oliver Terbu", "text": "<p>issue on trust model: <a href=\"https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/281\">https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/281</a></p>", "time": "2024-12-09T17:23:56Z"}, {"author": "Kristina Yasuda", "text": "<p>subjects too.....</p>", "time": "2024-12-09T17:23:58Z"}, {"author": "Watson Ladd", "text": "<p>@Oliver: that was just a question about what was meant. The trust issue discovery was as I was thinking over the weekend</p>", "time": "2024-12-09T17:24:28Z"}, {"author": "Kristina Yasuda", "text": "<p>one can absolutely add validation methods, with extensibility points in place - for issuer signature, that's jwt header, for holder, that's cnf key methods</p>", "time": "2024-12-09T17:24:46Z"}, {"author": "Watson Ladd", "text": "<p>you can't add one if what is trusted is just the issuer string.</p>", "time": "2024-12-09T17:25:18Z"}, {"author": "Watson Ladd", "text": "<p>because the issuer might not control that across the new validation method</p>", "time": "2024-12-09T17:25:32Z"}, {"author": "Richard Barnes", "text": "<p>206 DID methods at current count <a href=\"https://github.com/w3c/did-extensions/tree/main/methods\">https://github.com/w3c/did-extensions/tree/main/methods</a></p>", "time": "2024-12-09T17:25:33Z"}, {"author": "Michael Jones", "text": "<p>And counting...</p>", "time": "2024-12-09T17:26:56Z"}, {"author": "Kristina Yasuda", "text": "<p>validation is the combination of issuer identifier (in iss claim) and how to get the pub key to validate the signature by that issuer. they are related and both are extensible.</p>", "time": "2024-12-09T17:27:21Z"}, {"author": "Pieter Kasselman", "text": "<p>Are they all equally adopted?</p>", "time": "2024-12-09T17:27:26Z"}, {"author": "Kristina Yasuda", "text": "<p>i still believe cnf.did is the way to go. sd-jwt vc just says cnf claim. we define cnf.did in a separate small draft. problem solved (in my ideal world)</p>", "time": "2024-12-09T17:28:07Z"}, {"author": "Richard Barnes", "text": "<p>it seems like the important things are:</p>\n<ol>\n<li>We need to be able to support &gt;1 way to obtain a validated public key for an issuer (HTTPS + X.509 even without DID)</li>\n<li>It needs to be clear to a verifier which one it should use when verifying a given credential</li>\n</ol>", "time": "2024-12-09T17:28:28Z"}, {"author": "Watson Ladd", "text": "<p>let's say I create method B, but the namespace is the same as the issuers that exist. If people trust issuers without pinning down method, when method B is added kaboom.</p>", "time": "2024-12-09T17:28:46Z"}, {"author": "Richard Barnes", "text": "<p>oh and:</p>\n<ol start=\"3\">\n<li>We need to have a baseline set of methods</li>\n</ol>", "time": "2024-12-09T17:28:48Z"}, {"author": "Carsten Bormann", "text": "<p>Principle of Economy of Mechanism:<br>\n\"The protection mechanism should have a simple and small design.\"<br>\n[Saltzer, Schroeder (1975)]</p>", "time": "2024-12-09T17:34:18Z"}, {"author": "Kristina Yasuda", "text": "<p>impementing acts point to ARF and ARF includes sd-jwt and commision explicitly asked IETF about sd-jwt standardization. so let's not weaponize published IAs - there's nuance.</p>", "time": "2024-12-09T17:34:49Z"}, {"author": "Kristina Yasuda", "text": "<p>removing DID has a legitimate technical interoperability concerns</p>", "time": "2024-12-09T17:35:13Z"}, {"author": "Richard Barnes", "text": "<p>it is impossible to implement \"DID\"</p>", "time": "2024-12-09T17:36:02Z"}, {"author": "Richard Barnes", "text": "<p>because of the unbounded set of DID methods</p>", "time": "2024-12-09T17:36:15Z"}, {"author": "Richard Barnes", "text": "<p>so you can't possibly do interop testing if the requirement is \"do DID resolution\"</p>", "time": "2024-12-09T17:36:29Z"}, {"author": "Kristina Yasuda", "text": "<p>is there one DID method that everyone in DID ecosystem can live with?</p>", "time": "2024-12-09T17:36:51Z"}, {"author": "Henk Birkholz", "text": "<p>I think this is a w3c note doc: <a href=\"https://www.w3.org/TR/2024/NOTE-did-extensions-methods-20241119/\">https://www.w3.org/TR/2024/NOTE-did-extensions-methods-20241119/</a></p>\n<p>Is there a real chance that any of those is going to be standardized before this I-D will be published? If not, where does the interoperability come from?</p>", "time": "2024-12-09T17:37:03Z"}, {"author": "Henk Birkholz", "text": "<p>I am relatively new to this yes/no to did and only read up on the current status of did in June. And I am quite confused by how I cannot find a single did resolution/standard. Maybe someone knows better than me?</p>", "time": "2024-12-09T17:40:34Z"}, {"author": "Kristina Yasuda", "text": "<p>client_id_scheme!</p>", "time": "2024-12-09T17:41:22Z"}, {"author": "Kristina Yasuda", "text": "<p>that's what we need :)</p>", "time": "2024-12-09T17:41:28Z"}, {"author": "Daniel Fett", "text": "<p>yes :-)</p>", "time": "2024-12-09T17:41:30Z"}, {"author": "Daniel Fett", "text": "<p>Maybe as a prefix ;-)</p>", "time": "2024-12-09T17:41:45Z"}, {"author": "Kristina Yasuda", "text": "<p>yeah</p>", "time": "2024-12-09T17:41:50Z"}, {"author": "Kristina Yasuda", "text": "<p>these are all solvable problems, we just need to agree on the problem</p>", "time": "2024-12-09T17:42:04Z"}, {"author": "Watson Ladd", "text": "<p>i dont hear him</p>", "time": "2024-12-09T17:43:26Z"}, {"author": "Richard Barnes", "text": "<p>hopefully those two principles (extensibility + agreement between iss/ver) make sense</p>", "time": "2024-12-09T17:43:54Z"}, {"author": "Aaron Parecki", "text": "<p>clicking through the list of the 206 DID methods in that w3c note, I'm already finding many DID methods linked from there that have been abandoned/archived/404</p>", "time": "2024-12-09T17:44:44Z"}, {"author": "Kristina Yasuda", "text": "<p>what waston is saying is why we have client_id_scheme prefix for the verifiers in oid4vp. i think we should be careful if we are sure the same problem exists for the issuer.....</p>", "time": "2024-12-09T17:44:58Z"}, {"author": "Daniel Fett", "text": "<p>What @Watson is mentioning is exactly the discussion we had in OpenID4VP with the client_id \u2014 we need to what extent what we learned there applies here.</p>", "time": "2024-12-09T17:45:04Z"}, {"author": "Kristina Yasuda", "text": "<p>so far issuers have much less option how to sign the credential</p>", "time": "2024-12-09T17:45:16Z"}, {"author": "Steffen Schwalm", "text": "<p>the missing DID Standardization is no argument as this is done in CEN JTC 19</p>", "time": "2024-12-09T17:45:29Z"}, {"author": "Kristina Yasuda", "text": "<p>very very veyr strong ask - can people please separate if they talk about issuer or holder keys</p>", "time": "2024-12-09T17:45:37Z"}, {"author": "Kristina Yasuda", "text": "<p>well, then we should wait for CEN standardizing \"the\" DID method before adding anything to sd-jwt vc</p>", "time": "2024-12-09T17:46:33Z"}, {"author": "Oliver Terbu", "text": "<p>i see the issue but i don't like the prefix approach. i am in favor of having a dedicated claim with 1-2 well-defined limited values, e.g. x5c, https.</p>", "time": "2024-12-09T17:46:46Z"}, {"author": "Henk Birkholz", "text": "<p>@Steffen: is that transparent to this wg?</p>", "time": "2024-12-09T17:46:55Z"}, {"author": "Oliver Terbu", "text": "<p>or an array of possible values if an issuer wants to provide multiple options for one particular credential type</p>", "time": "2024-12-09T17:47:18Z"}, {"author": "Orie Steele", "text": "<p>for trust by reference fields (iss + kid / x5t / x5u)... the whole point of the hint is to get to a verification key... I don't see why DIDs need their own fields, they are just a string or uri that is not well understood outside of: <a href=\"https://www.w3.org/TR/controller-document/\">https://www.w3.org/TR/controller-document/</a></p>\n<p>That said, probably better to do a dedicated document that solves these issues for digital credential types that are not limited to jwt / sd-jwt.</p>", "time": "2024-12-09T17:47:19Z"}, {"author": "Steffen Schwalm", "text": "<p>@Kristina: an Umbrella Specification would solve the issue. you do not have to care about and Europe will have European standard within the SD JWT VC Sepc</p>", "time": "2024-12-09T17:47:42Z"}, {"author": "Oliver Terbu", "text": "<p>if there is one standardized DID method in the future, e.g., did:jwk, someone could write a profile doc of sd-jwt vc describing how DIDs can be used.</p>", "time": "2024-12-09T17:48:41Z"}, {"author": "Kristina Yasuda", "text": "<p>please do not threaten with umbrella specs</p>", "time": "2024-12-09T17:48:53Z"}, {"author": "Kristina Yasuda", "text": "<p>DIDs were never mandatory in sd-jwt vc</p>", "time": "2024-12-09T17:48:58Z"}, {"author": "Steffen Schwalm", "text": "<p>@Henk: The information yes and liaison with CEN JTC 19 would be helpful</p>", "time": "2024-12-09T17:49:04Z"}, {"author": "Steffen Schwalm", "text": "<p>@kristina: Nobody speaks about DID as mandatory but helpful to enable SD-JWT VC for certain use cases</p>", "time": "2024-12-09T17:49:54Z"}, {"author": "Aaron Parecki", "text": "<p>+1 to what Mike is saying</p>", "time": "2024-12-09T17:50:14Z"}, {"author": "Henk Birkholz", "text": "<p>+1 to what Mike is saying (as far as I understand it currently)</p>", "time": "2024-12-09T17:52:24Z"}, {"author": "Rohan Mahy", "text": "<p>+1 to Daniel and Kristina that we can describe specific DID methods in a separate document</p>", "time": "2024-12-09T17:53:59Z"}, {"author": "Steffen Schwalm", "text": "<p>@Kristina: Implementing Acts point to published standards for for QEAA Formats it`s W3CVCDM v1.1 und ISO mDL see </p>\n<p><a href=\"https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402977\">https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402977</a></p>", "time": "2024-12-09T17:54:16Z"}, {"author": "Daniel Bluhm", "text": "<p>Issuer's identifier as a DID is far more interesting than the Holder, IMO. I think most of the discussion is about the Issuer's DID.</p>", "time": "2024-12-09T17:54:17Z"}, {"author": "Christian Bormann", "text": "<p>Agreed Daniel, but important to distinguish between them in the discussion</p>", "time": "2024-12-09T17:54:58Z"}, {"author": "Christian Bormann", "text": "<p>mike doesn't seem to work, I'll try to fix but daniel &amp; kristina basically said most of wahat I wanted to say</p>", "time": "2024-12-09T17:55:56Z"}, {"author": "Orie Steele", "text": "<p>to me { cnf: { did } }, is just { cnf: { kid } }, but with an allow list string prefix... same thing is true for iss / sub which are just string or URIs... Like Mike Jones said, you need to agree on the prefix allow list and MTI to have any interop.</p>", "time": "2024-12-09T17:56:06Z"}, {"author": "Christian Bormann", "text": "<p>*mic, sorry &gt;.&lt;</p>", "time": "2024-12-09T17:56:22Z"}, {"author": "Kristina Yasuda", "text": "<p>I know Steffen - but IAs also say \" <br>\nthe reporting of wallet-relying parties to supervisory authorities established under Article 51 of Regulation (EU) 2016/679;</p>\n<p>to be updated on a regular basis to keep in line with technology and standards developments and with the work carried out on the basis of Recommendation (EU) 2021/946, and in particular the Architecture and Reference Framework.\"</p>", "time": "2024-12-09T17:56:56Z"}, {"author": "Kristina Yasuda", "text": "<p>and \"This Regulation lays down rules for the integrity and core functionalities of the wallets, to be updated on a regular basis to keep in line with technology and standards developments and with the work carried out on the basis of Recommendation (EU) 2021/946, and in particular the Architecture and Reference Framework.\"</p>", "time": "2024-12-09T17:57:19Z"}, {"author": "Kristina Yasuda", "text": "<p>there is an agreement to reopen IAs once standards referenced in ARF are final, so again, let's not weaponize current IAs</p>", "time": "2024-12-09T17:58:18Z"}, {"author": "Steffen Schwalm", "text": "<p>correct it might be updated but it`s not currently</p>", "time": "2024-12-09T17:58:22Z"}, {"author": "Kristina Yasuda", "text": "<p>@orie, agree, but does not look like sd-jwt vc will have anything MTI</p>", "time": "2024-12-09T17:58:57Z"}, {"author": "Steffen Schwalm", "text": "<p>and the reference to ARF is good but it does not make the ARF mandatory</p>", "time": "2024-12-09T17:59:01Z"}, {"author": "Kristina Yasuda", "text": "<p>and cnf is basically acting like client_id_scheme prefix in functionality</p>", "time": "2024-12-09T17:59:13Z"}, {"author": "Daniel Fett", "text": "<p>I have the feeling that we have an agreement here in the room on the big agenda items and what we need to discuss is how to best implement this in the specification.</p>", "time": "2024-12-09T17:59:17Z"}, {"author": "Kristina Yasuda", "text": "<p>it indirectly does</p>", "time": "2024-12-09T17:59:42Z"}, {"author": "Kristina Yasuda", "text": "<p>^ @steffen</p>", "time": "2024-12-09T17:59:50Z"}, {"author": "Steffen Schwalm", "text": "<p>@Kristina: but not legally mandatory unfortunately</p>", "time": "2024-12-09T18:00:18Z"}, {"author": "Steffen Schwalm", "text": "<p>but Art. 5b certification requirements reference 1025/2012 so European standards mandatorily  - that\u00b4s why CEN could be the solution here</p>", "time": "2024-12-09T18:01:02Z"}, {"author": "Steffen Schwalm", "text": "<p>@Daniel Fett: +1</p>", "time": "2024-12-09T18:01:19Z"}, {"author": "Kristina Yasuda", "text": "<p>i remember that SCITT story... good point, Henk</p>", "time": "2024-12-09T18:01:38Z"}, {"author": "Colton Wolkins", "text": "<p>In reference to did methods, methods like did:key, did:jwk, and did:peer include the keys in such a way that don't require external lookup. When a did relies on an external lookup (such as did:eth or did:web), it decreases the likelyhood of interoperability. Making the spec vague in a way that allows dids also decreases the likelyhood of interoperability, in my opinion.</p>", "time": "2024-12-09T18:02:09Z"}, {"author": "Markus Sabadello", "text": "<p>@henk This isn't really a valid pointm since DID resolvers don't have to be remote services. Typically they are just part of your own stack.</p>", "time": "2024-12-09T18:02:17Z"}, {"author": "Orie Steele", "text": "<p>Colton, those are just using a JWK / COSE Key as a confirmation method... but encoding it as a URN.</p>", "time": "2024-12-09T18:03:00Z"}, {"author": "Henk Birkholz", "text": "<p>@Markus: isn't that the point of did?</p>", "time": "2024-12-09T18:03:21Z"}, {"author": "Markus Sabadello", "text": "<p>@Henk no</p>", "time": "2024-12-09T18:03:37Z"}, {"author": "Henk Birkholz", "text": "<p>What's the distributed part then?</p>", "time": "2024-12-09T18:04:12Z"}, {"author": "Markus Sabadello", "text": "<p>@Henk The decentralized part is that DID can be created/resolved using decentralized infrastructures. But this doesn't mean that there has to be an untrusted, remote resolver service.</p>", "time": "2024-12-09T18:05:48Z"}, {"author": "Henk Birkholz", "text": "<p>Maybe supply chains depend more on several distributed revolvers than identity resolution of governments does</p>", "time": "2024-12-09T18:06:27Z"}, {"author": "Steffen Schwalm", "text": "<p>@henkl: Exactly</p>", "time": "2024-12-09T18:06:43Z"}, {"author": "Markus Sabadello", "text": "<p>Trust is complex and subjective.. Some people would say that HTTPS and root CAs cannot be trusted.</p>", "time": "2024-12-09T18:07:06Z"}, {"author": "Pierce Gorman", "text": "<p>Depends on the CA (or their jurisdiction)</p>", "time": "2024-12-09T18:08:20Z"}]