![](\"/user_uploads/2/e0/EOl992B9bv6hDSGmIsZ3MTug/Screenshot-2023-11-08-at-7.52.36-AM.png\")
really sorry, I'm not great with the meetecho tooling for the queue apparently
", "time": "2023-11-08T13:51:53Z"}, {"author": "Richard Barnes", "text": "\"optionally bound to a key\" :grimacing:
", "time": "2023-11-08T13:57:02Z"}, {"author": "Richard Barnes", "text": "the key binding is the only thing that makes the three-party model work!
", "time": "2023-11-08T13:57:30Z"}, {"author": "Richard Barnes", "text": "otherwise its an Aleph-Null-party model because each verifier can pass it to another verifier
", "time": "2023-11-08T13:58:02Z"}, {"author": "Brian Campbell", "text": "do we really need to have DIDs here?
", "time": "2023-11-08T14:00:26Z"}, {"author": "Richard Barnes", "text": "@Brian - I was just about to ask the same thing
", "time": "2023-11-08T14:00:40Z"}, {"author": "Richard Barnes", "text": "Oliver is in front of the room camera :)
", "time": "2023-11-08T14:01:22Z"}, {"author": "Judith Kahrer", "text": "Isn't \"obtaining issuer verification key\" the same for all JWTs?
", "time": "2023-11-08T14:02:33Z"}, {"author": "Aaron Parecki", "text": "\n\nsaying \"use DIDs\" is like saying \"use a protocol\"
\n
:sweat_smile: thank you richard
", "time": "2023-11-08T14:04:56Z"}, {"author": "Richard Barnes", "text": "@Aaron - That was me actually, don't want Brian to get blamed inappropriately :)
", "time": "2023-11-08T14:05:18Z"}, {"author": "Aaron Parecki", "text": "oh haha sorry I wasn't looking at the screen :)
", "time": "2023-11-08T14:05:29Z"}, {"author": "Brian Campbell", "text": "credit to Richard for that but he's not wrong
", "time": "2023-11-08T14:05:33Z"}, {"author": "Richard Barnes", "text": "this all seems like a bunch of unnecessary detail
", "time": "2023-11-08T14:09:25Z"}, {"author": "Richard Barnes", "text": "(this == credential type metadata)
", "time": "2023-11-08T14:09:59Z"}, {"author": "Richard Barnes", "text": "i could hold my nose and live with did:web
", "time": "2023-11-08T14:14:58Z"}, {"author": "Richard Barnes", "text": "but at that point, just use an HTTPS URL
", "time": "2023-11-08T14:15:15Z"}, {"author": "Tobias Looker", "text": "Im online :)
", "time": "2023-11-08T14:16:07Z"}, {"author": "Brian Campbell", "text": "did:web wouldn't be prohibited - it'd just be rolled up under the ecosystems can do what they need
", "time": "2023-11-08T14:17:44Z"}, {"author": "Daniel Fett", "text": "Richard Barnes said:
\n\n\nthe key binding is the only thing that makes the three-party model work!
\n
There are applications where key binding is not required or enforced. This allows for replaying credentials, but that may be intentional.
", "time": "2023-11-08T14:19:31Z"}, {"author": "Kristina Yasuda", "text": "Richard Barnes said:
\n\n\nOh I forgot to say -- I noted a couple minor things that i will get filed soon
\n
we used to have that, but we moved it to a separate repo for multiple reasons. there should be a pointer in the readme?
", "time": "2023-11-08T14:20:37Z"}, {"author": "Daniel Fett", "text": "Kristina Yasuda said:
\n\n\nRichard Barnes said:
\n\n\nOh I forgot to say -- I noted a couple minor things that i will get filed soon
\nwe used to have that, but we moved it to a separate repo for multiple reasons. there should be a pointer in the readme?
\n
There is.
", "time": "2023-11-08T14:21:30Z"}, {"author": "Tobias Looker", "text": "Apologies if there was a question I couldn't hear it
", "time": "2023-11-08T14:21:37Z"}, {"author": "Kristina Yasuda", "text": "Brian Campbell said:
\n\n\ndid:web wouldn't be prohibited - it'd just be rolled up under the ecosystems can do what they need
\n
well i really don't see the reason not to mention them in the spec if they are as non-normative as https or x5c
", "time": "2023-11-08T14:22:01Z"}, {"author": "Kristina Yasuda", "text": "Richard Barnes said:
\n\n\n(this == credential type metadata)
\n
can you elaborate?
", "time": "2023-11-08T14:22:20Z"}, {"author": "Richard Barnes", "text": "Daniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nthe key binding is the only thing that makes the three-party model work!
\nThere are applications where key binding is not required or enforced. This allows for replaying credentials, but that may be intentional.
\n
C'est magnifique, mais ce n'est pas la mod\u00e8le \u00e0 trois
", "time": "2023-11-08T14:23:34Z"}, {"author": "Richard Barnes", "text": "Kristina Yasuda said:
\n\n\nRichard Barnes said:
\n\n\n(this == credential type metadata)
\ncan you elaborate?
\n
The only thing we need for interop is that the issuer and the verifier agree on the semantic of the claims in the VC. We don't need a detailed, machine-readable description of the claims.
", "time": "2023-11-08T14:25:45Z"}, {"author": "Richard Barnes", "text": "You could certainly make such a thing, but it should be an optimization over a base content type indication scheme, basically a factory for new conten types
", "time": "2023-11-08T14:26:21Z"}, {"author": "Daniel Fett", "text": "Richard Barnes said:
\n\n\nDaniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nthe key binding is the only thing that makes the three-party model work!
\nThere are applications where key binding is not required or enforced. This allows for replaying credentials, but that may be intentional.
\nC'est magnifique, mais ce n'est pas la mod\u00e8le \u00e0 trois
\n
Of course it still is.
", "time": "2023-11-08T14:28:04Z"}, {"author": "Aaron Parecki", "text": "there are 7 people in the queue and 7 minutes left so GOGOGO
", "time": "2023-11-08T14:28:19Z"}, {"author": "Brian Campbell", "text": "it's not going to the AS first
", "time": "2023-11-08T14:29:10Z"}, {"author": "Richard Barnes", "text": "Daniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nDaniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nthe key binding is the only thing that makes the three-party model work!
\nThere are applications where key binding is not required or enforced. This allows for replaying credentials, but that may be intentional.
\nC'est magnifique, mais ce n'est pas la mod\u00e8le \u00e0 trois
\nOf course it still is.
\n
As above, it's an Aleph-Null-party model, since you can have an infinite chain of verifiers replaying the token to one another. Honestly, I'm kind of baffled as to why anyone wants this. Key binding is not that hard.
", "time": "2023-11-08T14:29:26Z"}, {"author": "Jacob Ideskog", "text": "There are now 4 different PoPs in OAuth Ecosystem
\n+1 Aron
", "time": "2023-11-08T14:32:28Z"}, {"author": "Tobias Looker", "text": "@Aaron would you mind filing an issue so we could discuss what methods of client authentication you would like to use with this attestation mechanism?
", "time": "2023-11-08T14:33:28Z"}, {"author": "Daniel Fett", "text": "Richard Barnes said:
\n\n\nDaniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nDaniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nthe key binding is the only thing that makes the three-party model work!
\nThere are applications where key binding is not required or enforced. This allows for replaying credentials, but that may be intentional.
\nC'est magnifique, mais ce n'est pas la mod\u00e8le \u00e0 trois
\nOf course it still is.
\nAs above, it's an Aleph-Null-party model, since you can have an infinite chain of verifiers replaying the token to one another. Honestly, I'm kind of baffled as to why anyone wants this. Key binding is not that hard.
\n
A Verifier might be interested in learning that a credential was issued (e.g., XYZ License for John Doe), but may not care about who presents it in that moment.
", "time": "2023-11-08T14:34:17Z"}, {"author": "Dmitry Telegin", "text": "the attestation part seems to be heavily relying on TPM/SE or similar; does that mean that in practice we'll be able to attest mobile apps only?
", "time": "2023-11-08T14:35:51Z"}, {"author": "Philippe De Ryck", "text": ":wave:
", "time": "2023-11-08T14:36:08Z"}, {"author": "Philippe De Ryck", "text": "(that was me waving)
", "time": "2023-11-08T14:36:31Z"}, {"author": "Tobias Looker", "text": "@Dmitry, no not necessarily, technically the client instance can use a key secured in anyway that the client backend/attester is willing to accept
", "time": "2023-11-08T14:37:14Z"}, {"author": "Dmitry Telegin", "text": "@Tobias, so in theory that could be even a web SPA using WebCrypto keystore?
", "time": "2023-11-08T14:38:36Z"}, {"author": "Kristina Yasuda", "text": "Richard Barnes said:
\n\n\nThe only thing we need for interop is that the issuer and the verifier agree on the semantic of the claims in the VC. We don't need a detailed, machine-readable description of the claims.
\n
thank you! that was my intuition too. defining what type means should probably be separate from type leading to something machine readable. at the same time, discovering json schema and display informaiton it is a pain point so machine readable thing is needed to be defined somewhere...
", "time": "2023-11-08T14:39:05Z"}, {"author": "Tobias Looker", "text": "@Dmitry If the client backend were willing to accept it then technically yes
", "time": "2023-11-08T14:40:30Z"}, {"author": "Richard Barnes", "text": "Daniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nDaniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nDaniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nthe key binding is the only thing that makes the three-party model work!
\nThere are applications where key binding is not required or enforced. This allows for replaying credentials, but that may be intentional.
\nC'est magnifique, mais ce n'est pas la mod\u00e8le \u00e0 trois
\nOf course it still is.
\nAs above, it's an Aleph-Null-party model, since you can have an infinite chain of verifiers replaying the token to one another. Honestly, I'm kind of baffled as to why anyone wants this. Key binding is not that hard.
\nA Verifier might be interested in learning that a credential was issued (e.g., XYZ License for John Doe), but may not care about who presents it in that moment.
\n
I would be interested to understand the use case where the Verifier gets useful information from the credential, but does not associate it with the presenter.
\nBTW that still doesn't seem like a three-party model, because you don't have a meaningful Holder -- the Holder is just a store-and-forward relay for the credential, doesn't have an actual role in the protocol. Even if you ignore replay, it's a two-party model.
", "time": "2023-11-08T14:40:55Z"}, {"author": "Daniel Fett", "text": "Kristina Yasuda said:
\n\n\nRichard Barnes said:
\n\n\nThe only thing we need for interop is that the issuer and the verifier agree on the semantic of the claims in the VC. We don't need a detailed, machine-readable description of the claims.
\nthank you! that was my intuition too. defining what type means should probably be separate from type leading to something machine readable. at the same time, discovering json schema and display informaiton it is a pain point so machine readable thing is needed to be defined somewhere...
\n
The current thinking is that defining any metadata for vct is optional. It is first of all a means to distinguish types, and if verifier and issuer agree and have all information, there is no need to actually provide the metadata somewhere.
", "time": "2023-11-08T14:41:28Z"}, {"author": "Richard Barnes", "text": "I don't mean to pick on the no-key-binding thing just to be pedantic about modeling. There are significant differences in the security properties you get in the two cases, so they should not be confused.
", "time": "2023-11-08T14:42:51Z"}, {"author": "Richard Barnes", "text": "In other words, there's a pretty exact analogy between VC-without-KB and \"alg\": \"none\". Here's a thing that is syntactically similar to a thing that provides a security property, but does not actually provide that property. You will get exactly the same bugs and vulnerabilities as with \"alg\": \"none\".
Obviously, I don't object to there being JWTs that don't have key binding, and even borrowing some of the syntax. But they should be clearly marked as not VCs. Much like \"alg\": \"none\" JWS objects should have been clearly marked as not JWS.
Dmitry Telegin said:
\n\n\n@Tobias, so in theory that could be even a web SPA using WebCrypto keystore?
\n
I would argue that a SPA using a WebCrypto key is not attestation at all, just plain client authentication
", "time": "2023-11-08T14:47:42Z"}, {"author": "Daniel Fett", "text": "Richard Barnes said:
\n\n\nDaniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nDaniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nDaniel Fett said:
\n\n\nRichard Barnes said:
\n\n\nthe key binding is the only thing that makes the three-party model work!
\nThere are applications where key binding is not required or enforced. This allows for replaying credentials, but that may be intentional.
\nC'est magnifique, mais ce n'est pas la mod\u00e8le \u00e0 trois
\nOf course it still is.
\nAs above, it's an Aleph-Null-party model, since you can have an infinite chain of verifiers replaying the token to one another. Honestly, I'm kind of baffled as to why anyone wants this. Key binding is not that hard.
\nA Verifier might be interested in learning that a credential was issued (e.g., XYZ License for John Doe), but may not care about who presents it in that moment.
\nI would be interested to understand the use case where the Verifier gets useful information from the credential, but does not associate it with the presenter.
\nBTW that still doesn't seem like a three-party model, because you don't have a meaningful Holder -- the Holder is just a store-and-forward relay for the credential, doesn't have an actual role in the protocol. Even if you ignore replay, it's a two-party model.
\n
Yes, the holder would be 'degraded' to stora-and-forward in this case.
\nExamples: For better or worse, covid vaccination credentials were not key-bound. That was convenient for paper-based presentation and having your family's credentials on your own phone.
\nAnother real-life example: I recently had to sent a picture of my physical driver's license to a company just to prove that it exists (for insurance purposes, so that they can record me as a permitted driver for a friend's car). They didn't care who presented it. So while the credential supports holder binding (here via biometrics), not all verifiers are interested in checking it.
", "time": "2023-11-08T14:48:50Z"}, {"author": "Aaron Parecki", "text": "Aaron Parecki said:
\n\n\nDmitry Telegin said:
\n\n\n@Tobias, so in theory that could be even a web SPA using WebCrypto keystore?
\nI would argue that a SPA using a WebCrypto key is not attestation at all, just plain client authentication
\n
Apple does have a JS attestation API already, it's called Private Access Tokens
", "time": "2023-11-08T14:49:58Z"}, {"author": "Aaron Parecki", "text": "do we need to break out these conversations into separate threads? that's like zulip's whole concept :joy:
", "time": "2023-11-08T14:50:16Z"}, {"author": "Richard Barnes", "text": "kind of a fail that Zulip UI failed to direct things into threads
", "time": "2023-11-08T14:51:00Z"}, {"author": "Justin Richer", "text": "I had no idea there were threads
", "time": "2023-11-08T14:51:12Z"}, {"author": "Aaron Parecki", "text": "the problem is it's not threads like you're used to in slack, it's more like separate sub-channels
", "time": "2023-11-08T14:51:17Z"}, {"author": "Richard Barnes", "text": "@Justin Richer note that the threads are only in Zulip, not MeetEcho
", "time": "2023-11-08T14:51:29Z"}, {"author": "Richard Barnes", "text": "@Daniel Fett we should probably talk offline :)
", "time": "2023-11-08T14:51:41Z"}, {"author": "Justin Richer", "text": "I'm on a web page, I don't even know what's going on here :sweat_smile:
", "time": "2023-11-08T14:52:12Z"}, {"author": "Aaron Parecki", "text": "i'm also on a web page it's just a fancier one
", "time": "2023-11-08T14:52:26Z"}, {"author": "Brian Campbell", "text": "the view of this chat in MeetEcho is inscrutable Screenshot-2023-11-08-at-7.52.36-AM.png
\noh my god
", "time": "2023-11-08T14:54:08Z"}, {"author": "Daniel Fett", "text": "Scroll really quickly!
", "time": "2023-11-08T14:54:29Z"}, {"author": "Justin Richer", "text": "Mobile site just gives up. Screenshot_20231108_155450_Chrome.png
\n![](\"/user_uploads/2/d5/7zO9aInWofjqZ_WdyNtKxoRK/Screenshot_20231108_155450_Chrome.png\")
the MeetEcho chat is amazingly broken. my favorite part is that you they force you to use their emoji picker, which is totally broken :100:
", "time": "2023-11-08T14:57:06Z"}, {"author": "Richard Barnes", "text": "(that's supposed to be :100: but displays as \ud83d\udd51 in MeetEcho ???)
", "time": "2023-11-08T14:57:44Z"}, {"author": "Richard Barnes", "text": "this diatribe makes sense in Zulip, but not in MeetEcho
", "time": "2023-11-08T14:58:12Z"}, {"author": "Daniel Fett", "text": "As long as there is no XSS <hr>...
", "time": "2023-11-08T14:58:14Z"}, {"author": "Aaron Parecki", "text": "ok what meetecho chat are you seeing? when I click the chat thing it just launches zulip
", "time": "2023-11-08T14:58:30Z"}, {"author": "Aaron Parecki", "text": "ohhh the new beta one
", "time": "2023-11-08T15:00:08Z"}, {"author": "Brian Campbell", "text": "Richard Barnes said:
\n\n\nDaniel Fett we should probably talk offline :)
\n
bit more context wrt key binding is that there's a lot of strong security conversations in the base sd-jwt doc like https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#name-key-binding yet at the same time there's one very security aware person suggesting that it should be looser https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/368
", "time": "2023-11-08T15:00:14Z"}, {"author": "Brian Campbell", "text": "^ the analogy to alg:none isn't wrong but it's complicated
", "time": "2023-11-08T15:01:16Z"}, {"author": "Kristina Yasuda", "text": "ISO mDL is sent over OpenDI4VP :) so if you reference it already that is all you need I think :)
", "time": "2023-11-08T15:05:17Z"}, {"author": "Dmitry Telegin", "text": "@Aaron Parecki so, until we have JS attestation for all major platforms/browsers (be it Private Access Tokens or Web Integrity API or whatever), we can't speak of efficient SPA attestation, right?
", "time": "2023-11-08T15:05:57Z"}, {"author": "Aaron Parecki", "text": "I mean, you can support attestation on only the platforms that have the API available, which is another reason it's not the same as client authentication
", "time": "2023-11-08T15:06:26Z"}, {"author": "Judith Kahrer", "text": "Attestation raises concerns in the open source community. Especially if attestation relies on the mechanisms provided by a few global players...
", "time": "2023-11-08T15:12:07Z"}, {"author": "Tobias Looker", "text": "To be clear though the attestation in our draft is different from platform attestations, a client backend might require an instance to provide a platform attestation but that isn't strictly required
", "time": "2023-11-08T15:12:14Z"}, {"author": "Aaron Parecki", "text": "@Tobias Looker can you give a concrete example of an attestation that is not a platform attestation? Like describe how the keys were deployed, what information is conveyed, etc
", "time": "2023-11-08T15:13:44Z"}, {"author": "Judith Kahrer", "text": "I know that the draft technically does not depend on platform attestation. I just want to point out that from a security point of view attestation (as a concept) may be great but it also may have unintended consequences.
", "time": "2023-11-08T15:15:17Z"}, {"author": "David Waite", "text": "The at internet revocation number - what is it based on?
", "time": "2023-11-08T15:15:49Z"}, {"author": "Aaron Parecki", "text": "@Judith Kahrer it's not like the draft is inventing the concept of attestation. The concept already exists, and people have deployed platform attestation with OAuth clients already, so this is just a way to standardize it.
", "time": "2023-11-08T15:17:16Z"}, {"author": "Tobias Looker", "text": "@Aaron, I believe Pieter working on workload identity usecases had a couple that were applicable to ephemeral software instances that are spun up and need to authenticate and obtain an access token from an AS, I'm forgetting the specifics right now
", "time": "2023-11-08T15:18:39Z"}, {"author": "Tobias Looker", "text": "Which dont use platform attestations in anyway
", "time": "2023-11-08T15:19:16Z"}, {"author": "Aaron Parecki", "text": "omg @Justin Richer the W3C version has this:
\n\n", "time": "2023-11-08T15:28:32Z"}, {"author": "Kristina Yasuda", "text": "\"id\": \"https://example.com/credentials/status/3#94567\"
\n
yes, we are competing with w3c statuslist is i think the short answer and maybe we should think it through a bit more
", "time": "2023-11-08T15:28:47Z"}, {"author": "Kristina Yasuda", "text": "+1 to token status list as a title please
", "time": "2023-11-08T15:29:17Z"}, {"author": "Kristina Yasuda", "text": "Aaron Parecki said:
\n\n\nomg Justin Richer the W3C version has this:
\n\n\n\"id\": \"https://example.com/credentials/status/3#94567\"
\n
that id \"It MUST NOT be the URL for the status list.\"
it is an RDF id
", "time": "2023-11-08T15:30:14Z"}, {"author": "Aaron Parecki", "text": "oh god
", "time": "2023-11-08T15:30:44Z"}, {"author": "Aaron Parecki", "text": "well reading through this W3C version, I see why nobody in their right mind would use this for JWT access tokens
", "time": "2023-11-08T15:31:03Z"}, {"author": "Kristina Yasuda", "text": "yeap
", "time": "2023-11-08T15:31:18Z"}]