... register soon, early bird discount is over, but you can still get a topic paper discount
Andrew Hughes: Please register soon if you haven't yet, and please submit papers ✪
Joe Andrieu: Want to mention we are past the paper deadline, so get it in. Also, the last day is the 22nd to register before on-site pricing kicks in ✪
Christopher Allen: I'm not seeing examples of JWTs in DID method specs, could we take this to the next level ? ✪
... what are we missing to take this to the next level?
Manu Sporny: The way uPort has approached this is as a wrapper around the information than as a proof format. ✪
... we added RSA2018 signatures in the hopes this would be what they use, but instead they wrap the VC ir DID doc and shove the whole thing in a JWT, rather than using a proof format.
... looks like there's a path forward to using ld proofs with zkps, bitcoin, proof of work
... it is up to the users of JWTs to determine how they will use it in their specs
Kim Hamilton Duffy: I am back, let me know if connection is better this time ✪
... action items need some owners
... does anyone have proposals for who can drive the work?
Manu Sporny: Oliver has done a great job of engaging. Not volunteering him, but he would be great. ✪
Joe Andrieu: OK - I’ll think about possible alternative lablels [scribe assist by Andrew Hughes] ✪
... sustainability: no vendor lock in
Joe Andrieu: Yes - thanks - because ‘sustainability’ evokes renewable/cost efficiency etc - which is part [scribe assist by Andrew Hughes] ✪
Joe Andrieu: All of this language is new, so we'd like editing ✪
... Going to the queue
Justin_R: I'm not familiar with the W3C use case documents, but from an outsider perspective, this reads like a set of solutions without stated problems. Adding requirements may help. ✪
Manu Sporny: Want to do some level setting. why are we focusing on this? the DID charter proposal went to advisory review. w ✪
Heather Vescent: +1 Justin. This does not tell the bigger story, it gets into the technical weeds, ✪
... we gave them a heads up, but the use case doc was an old, unedited google doc.
... they want a ReSpec doc of use cases with some more polish.
To be clear, it's more that the document doesn't tell me what problems it's addressing so I don't know if I care about the solutions. ✪
... not sure if leading with the requirements will be the best. Perhaps following the VC use cases approach could work.
Heather Vescent: Also, I feel like all the work on the other use case document was pointless. I don't see any of that work reflected in this document. Which was my main concern when we spent all that time way back then doing those. Why did we bother doing all those if they don't funnel into here? ✪
... DIDs are challenging to talk about. Feedback is that use cases haven't been helpful in leading to understanding.
Ted Thibodeau: Challenge (problem), solution (DID), application of solution (use case scenario) ✪
Heather Vescent: I was promised that back then, those use cases would not be for naught, but it seems that this has happened. ✪
Mike Lodder: Talking about cencorship and use cases, we could talk about how in some countries it is not legal to access certain types of data, e.g. GDPR. It may make sense for the DID to split based on what it has access to. Cencorship may not always be a negative. ✪
Joe Andrieu: Interesting idea, probably at a different layer than DIDs ✪
Mike Lodder: Data access control, services could use cencorship ✪
Christopher Allen: Two comments: one of the benefits of this area is there are cryptographic problems such as selective disclosure etc. that haven't been realized yet. ✪
... to the larger question, I want to go even further in reducing use cases. The long-term educational claims use case where you could have claims where keys and parties may change over time, but the signatures don't change, even after 30 years.
... another one: the travel one, crossing borders (we talked about this at TPAC) different parties have different authority over different parts of travel.
... all these different identifier block this in different ways. DIDs help unblock this.
... less is more. The use cases are interesting, but we should lead with what is driving adoption now.
Joe Andrieu: One challenge with these use cases is that they bleed into VC use cases. ✪
Dave Longley: Sounds like "using a Verifiable Credential" is a use case itself ✪
... enabled by a DID, but more focused on VCs.
... we need to point out what DIDs uniquely make possible
Jonathan Holt: My issue isn't with use cases, but with the charter. ✪
... Is DID specific to W3C community, action items, or credo?
... so much of the DID happens in the realm of data democritization and self-sovreignty. Concerned that the W3C will end up being a members only club.
Manu Sporny: You raise a good point, we need to address that as the WG takes form. ✪
... back to use cases, the language should be more positive, e.g. censorhip-resistant over anti-cencorship.
... want to underscore what Chris said. When we talk about DID use cases we go high level, these are verifiable credentials.
... the W3C AC is very well versed in focused charters. Hard for them to link how this new identifier enables the high level use cases.
... need some glue in there now, otherwise it won't go well with AC.
... need to focus on use cases that only DID specific
... have an identifier with cryptographic control, service discovery, and auditability of key rotations.
... this will help the AC focus on that DIDs enable that other things don't
Bohdan Andriyiv: Want to draw attention to longevity of DIDs. What differentiates DIDs from other identifiers is lifelong characteristic of DIDs. ✪
... high stakes cooperation. Democracy, decentralized government. Should have a use case for high-stakes long term cooperation.
Joe Andrieu: One thing that would greatly improve that use case is if the description outlines what actions the individuals would take. ✪
Kim Hamilton Duffy: I'm having a hard time reconciling the feedback when I look at the EDU use case. On the one hand, I'm hearing the use cases are too technical; on the other I'm hearing they doesn't spell out the details enough. It would be helpful to discuss specifics of 1 use case ✪
... the individual interactions that drive the scenario would be useful
Adrian Gropper: I think the very important reason to do the use cases, is the business case for self-sovereign identity. ✪
... the adoption model should answer the question: what should the issuer, holder and verifier have to do about DIDs.
Kim Hamilton Duffy: Here's a different angle: of the use cases, which one is closest to a "good" one by AC standards. What is it lacking to make it better? ✪
... if we focus the use cases on service discover etc. we will miss the business case.
Joe Andrieu: One of the things we have in the VC use cases document. We have the mechanistic use cases about what the individual entity can do, not the high level narrative. ✪
Manu Sporny: We called them User Roles, User Needs, and User Tasks... I think it was very useful. ✪
... I think the pattern we have in the other document is useful: problem domain and solution domain
Joe Andrieu: We have these 15 features, tried to break them down into what they provide as key benefits ✪
... sensitive to need to phrase them more positively, but is anything missing?
Christopher Allen: Keep on coming back to future proofing. Use of identifiers in the past hasn't addressed this problem. ✪
... this isn't acceptable today. We're enabling new methods of support for longevity and future proofing.
Adrian Gropper: +1 To logevity as reason for SSI ✪
... this is an essential core value proposition
Honest back-channel question, doesn't this just move the assumptions on longevity to the resolution side? ✪
Which is the real problem with all legacy identifier systems too, when you get down to it ✪
Kim Hamilton Duffy: I like the problem domain / solution domain idea; I think it would help address my question above (reconciling the too-technical feedback with the not-precise-enough feedback) ✪
Joe Andrieu: We have rotation, crypto future proof, organizational end-of-life longevity. These are all attempts to capture the future proofing. ✪
@Manu right but that means that it assumes the network will continue to run and the government structure won't fall, right? ✪
Manu Sporny: @Justin_R, you get more things w/ DIDs... not just the possibility of a more decentralized identifier network or governance structures... other things are key rotation tied to a long lived auditable identifier. ✪
Joe Andrieu: Thanks all, we will be quickly iterating. ✪
Manu Sporny: @Justin_R, so people tend to say "what does the *one* thing DIDs do?" -- and it's not just one thing, it's a combination of things... that because it does that combination of things, certain things are enabled. ✪
Manu Sporny: @Justin_R, like, you can have key rotation w/ no auditability... and while that's helpful (you can rotate keys), you don't know when people did the rotation, so you can't go back in time and check signatures from 15 years ago (as a hand-wavy example) ✪