3G/ Revocation: Introduction & Overview - goal is to connect
Revocation: Introduction and Overview - Goal Is To Connect
Tuesday 3G
Convener: Andreas Freitag
Notes-taker(s): Chat and edit from Andreas Freitag
Tags for the session - technology discussed/ideas considered:
- revocation #privacy #standards
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Link to presentation:
https://drive.google.com/file/d/1HBr2VinzbJxq8dOs4b398tOUbRXmhraE/view?usp=sharing
ZOOM CHAT ( Edited and discussion sorted to headlines):
QUESTIONS addressing cryptographic accumulators with delta files
20:37:49 From Rouven Heck1 to Everyone : Ever holder needs to update the Witness file, even if their stuff is not updated, correct?
20:38:24 From Micha Kraus to Everyone : Yes, on each accumulator update
20:39:04 From Paul DIetrich to Everyone : Is that pushed to all credential holders or do they just go get it when they need to present next time?
20:40:52 From Christian Bormann to Everyone : afaik normally it's not pushed, wallets get it when they need to present a proof of non-revocation (could also be done with certain intervals)
Andreas F.: You can implement in different ways.
20:41:36 From Dominic Wörner to Everyone : In Indy, updates/deltas are on the ledger. Depends on the wallet implementation when they fetch the updates
20:48:36 From Jeremie Miller to Everyone : Short expiration is exactly how OAuth/OIDC work w/ access token (and refresh tokens to update them), I don't believe scalability is really an issue with this approach given its adoption.
20:48:51 From Michael Lodder to Everyone : but privacy is
20:48:56 From Paul DIetrich to Everyone : thanks. Which of these methods does CredentialStatusXXXX use?
20:49:43 From Brian Richter to Everyone : List based I believe Paul
20:52:22 From Rouven Heck1 to Everyone : I’m wondering what credentials have practical use-cases if they are not tight to an individual / entity
20:52:37 From Kristina Yasuda1 to Everyone : like coupons?
20:53:06 From Rouven Heck1 to Everyone : ok, in this use-cases - what are the privacy concerns?
20:53:36 From Stephen Curran to Everyone : Proving age?
20:54:28 From Rouven Heck1 to Everyone : Proving age in which use-case? Entering a bar - needs your photo. Ordering something online - requires your address, etc.
20:54:49 From Rouven Heck1 to Everyone : if it’s just an age proof without anyting - wouldn’t this be something whcih can be shared easily?
One ring to rule them all, one ring to don't find them?
Andreas: I wish for a privacy preserving, scalable solution and the SSI community should agree on one (but not unlimited number) revocation method
20:56:00 From Rouven Heck1 to Everyone : @Andreas - why is your wishlist including that it’s only one revocation list? Don’t you think that it would be useful to use different methods depending on use-cases?
Andreas: Multiple methods would cause a lot of implementing effort for an agent which want to be interoperable. A second challenge is to keep privacy level high.
With a limited and agreed implementations privacy-by-design can be ensured.
20:59:15 From Paul DIetrich to Everyone : As far as I can tell the SSI community hasn’t select one method for anything yet. I hope this changes the game.
20:59:51 From Kristina Yasuda1 to Everyone : ^ so true
21:00:32 From Rouven Heck1 to Everyone : I would argue it’s not a desirable outcome
21:00:38 From Rouven Heck1 to Everyone : (at least not yet)
21:05:31 From Jeremie Miller to Everyone : +1 privacy by design!
21:05:32 From Karim Stekelenburg to Everyone : +9000!
21:06:19 From Michael Lodder to Everyone : +++
21:07:52 From Paul DIetrich to Everyone : How many credential revocations standards exist today?
Andreas: It is realized with lists/hidden list. The only implementation with cryptographic accumulators I know is the indy implementation.
21:19:19 From Rouven Heck1 to Everyone : @Andreas - what are we doing if the new approach with the Silverbullet will not work? :)
21:30:32 From Andreas Freitag to Everyone : @Rouven search a new one
“Standards”
21:09:25 From Paul DIetrich to Everyone : these are drafts right now? or have they been standardized.
Andreas: Yes, no standards at the moment.
21:10:36 From Kristina Yasuda1 to Everyone : no real standardization for 1 and 3, for 2, this is the one: https://w3c-ccg.github.io/vc-status-rl-2020/
21:11:03 From Kristina Yasuda1 to Everyone : I meant no real standardization *needed* for 1 and 3
21:11:59 From Paul DIetrich to Everyone : I get that for 3, but for #1 there has to be some kind of API?
21:12:29 From Michael Lodder to Everyone : how many ways are there to check for revocation with x509 certificates
Driving licence use case
21:02:26 From Michael Shea to Everyone : how many driver’s licenses are there in Austria?
Andreas: we have about 4Mio in Austria. For our testing we decide to have a setup with 10Mio items.
21:02:40 From Michael Lodder to Everyone : we started with w
21:02:49 From Michael Lodder to Everyone : revoke 600/day, add 1K/day
Almost every use-case / customer needs revocation
21:06:39 From Kristina Yasuda1 to Everyone : maybe you realize you gave an entrance pass to a criminal and want to revoke it within an hour...
Miscellaneous
21:08:49 From Kristina Yasuda1 to Everyone : one is Issuer call-home - you put that endpoint in the credential; Credential revocation list 2021 in W3C CCG; and no revocation needed
21:10:06 From Michael Shea to Everyone : IoT is very broad, if the IoT is a Medical device the requirements are very different
21:11:55 From Karim Stekelenburg to Everyone : Will BBS+ revocation lower the performance issues for JSON-LD once it’s there?
PRIVACY & Revocation by API
21:12:36 From Kristina Yasuda1 to Everyone : Issuer offers an API, and you put a link to that API inside the credential which verifier hits?
21:13:06 From Paul DIetrich to Everyone : But what do I get when I call it? Does 200 mean its OK?
21:13:07 From Michael Lodder to Everyone : @Kristina then you get correlation and disclosure
21:13:21 From Michael Lodder to Everyone : you get tracked by the issuer and every verifier
21:13:30 From Michael Lodder to Everyone : you don’t want the protocol to betray you
Andreas: It has disadvantages in privacy
21:13:34 From Michael Shea to Everyone : +1 Andreas
21:13:39 From Jeremie Miller to Everyone : +1 Andreas!
21:13:40 From Michael Lodder to Everyone : we have enough of those already
21:13:46 From Kristina Yasuda1 to Everyone : pairwise DIDs can prevent RP correlation, but yeah IdP correlation is there
21:13:53 From Stephen Curran to Everyone : +1 Andreas
21:13:57 From Rouven Heck1 to Everyone : It depends on who your customers are … ;)
21:14:14 From Michael Lodder to Everyone : DIDs don’t get you correlation, credential presentation could without ZKPs
21:14:25 From Rouven Heck1 to Everyone : governments and big corporate might have other requirements than peer to peer use-cases
21:14:32 From Kristina Yasuda1 to Everyone : I am listing options and +1 to Rouven, some issuers ask for the call home...
21:15:08 From Kristina Yasuda1 to Everyone : if you have a different DID in each credential of the same content issued per RP, that prevents correlation
21:15:37 From Michael Lodder to Everyone : its only prevented if its never disclosed
21:15:46 From Michael Lodder to Everyone : if the DID is revealed, its correlatable
21:16:01 From Michael Lodder to Everyone : especially since its a unique number
