DID WG Topic Call on Issue Processing Working Session — Minutes

Date: 2021-01-19

Attendees

Present: Markus Sabadello, Manu Sporny, Brent Zundel, Shigeya Suzuki, Kyle Den Hartog, Ted Thibodeau Jr., Tobias Looker, Daniel Burnett, Drummond Reed, Christopher Allen, Jonathan Holt, Adrian Gropper, Grant Noble

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Manu Sporny, Tobias Looker

Brent Zundel: Welcome all – this is a working session.

1. Diagram in issue 453

See github issue #453.

Shigeya Suzuki: I have a drawing, need feedback
… original concern I had was with original image
… the image in the document today mixes data relationships – trying to create relationship between VDR and DID Document, and also try to clearly differentiate functionality and data relationship – know that there is a discussion going on between resolution/dereferencing – how to draw this might be debatable.
… is the relationship clear?

Manu Sporny: We’re showing data and systems. Maybe what’s missing here is the resolver, I think it was in the previous diagram but not this one. The question is what are we trying to show here.
… In the VC data model, we only showed the entities and information. But this is more like concepts. The big challenge is we’re mixing conceptual stuff with entities. It may be best to create two different diagrams.

Shigeya Suzuki: yes, I was thinking in that way too – responding to manu’s comments – can we have more than one diagram?

Manu Sporny: Yes, anything that improves the specification is fine.

Shigeya Suzuki: for this diagram, I’m trying to replace the diagram if possible…
… we may need more diagrams

Drummond Reed: The reason I agree with that is I spent time w/ Amy on developing the diagram - about as accurate as we could get at the time.
… If there is additional information, additional diagrams would be good.

Justin Richer: Yes, somewhat of a metapoint about big diagrams… with this many layers, it’s difficult for someone looking at it to figure out what they’re supposed to be getting out of it.
… It’s often beneficial to decompose layered diagrams into multiple diagrams w/ accompanying text… not to say it’s easy, visual design is difficult to pull off.
… With some NIST documents I’ve worked on recently, we’ve been able to split into multiple diagrams that tell one part of the story - those seem to have been better received.
… DID URL and Resources might be different story.
… multiple related pictures might be beneficial here.

Shigeya Suzuki: Yes, getting more and more difficult – leading discussion – last weeks special call, seems to be difficult to think about this.
… I will try, but if I fail to capture it, I’ll fall back to the original one… not touch the current figure - we’ll see how much progress I can make.

Brent Zundel: Anyone else have any PRs that they’re struggling with?

Shigeya Suzuki: (Follow-up to the discussion on #453, see the current version for the reference – I will put the link to the issue)

2. Persistence

See github pull request #457.

Drummond Reed: This is the current note on persistence – previewing
… Taking in content from Kyle…
… would like feedback from Joe

Joe: I have issues with this language, going back to XDI, IIW, Rebooting/elsewhere – DIDs are not bound permanently to anything, and I think it’s going to be a big issue to talk about DIDs in this fashion – you might as tattoo a number to your neck or implant a microchip.

Joe Andrieu: Any DID I use, shouldn’t be permanently bound to me, language has been rooted undermines the point as to how many of us are here.

Brent Zundel: Would it be fair to say you support getting rid of this note?

Joe Andrieu: I think we should go further – all identifiers can’t be bound permanently – we need to explain how this creates security problems on how this particular identifiers?

Drummond Reed: Have you read this PR?

Joe Andrieu: Yes, “permanently bound” is the issue?

Drummond Reed: Can I try to explain how this takes your viewpoint into account.

Joe Andrieu: Well, I wrote text, but it wasn’t incorporated.

Justin Richer: change “permanently” to “persistently”? 🤷‍♀️

Brent Zundel: Current DID Core spec has a note on persistence – Drummond is trying to fix it to address concerns that have been brought up.
… new text feels like an improvement.

Tobias Looker: ^ worth discussing that proposal justin_r it is a note on persistence at the end of the day

Brent Zundel: Drummond has proposed some text to improve things, let’s try to assist with concrete modifications.

Drummond Reed: Different point of view - I appreciate use cases for people and need for best privacy features we can provide - herd privacy, etc. There are other use cases, DIDs for information use cases – software, IoT devices, security architectures around assumptions or policies on subject/call. DIDs were originally URNs, all persistent identifiers, we moved away from that.

Markus Sabadello: There’s an entire conference about persistent identifiers! Next week! https://pidapalooza2021.sched.com/

Drummond Reed: Original note said that, we revised it to say what it says in green - if you need, as DID Controller, your policy is to have a permanent binding, architecture of DID infrastructure, DID Method you would choose, would support that (but not required).
… It’s up to their policies, did my best to reflect that – want to make it clear - permanent binding, there are use cases for it – don’t know why that end of the spectrum isn’t provided.

Christopher Allen: I may have different concerns than Joe on this – I think I’m in general more skeptical in last year “someone needs it so we need to add it in”
… I’m skeptical right now, don’t understand Joe’s argument enough to make a concrete suggestion – maybe Joe needs a PR?

Brent Zundel: This is the only PR currently.
… Recommend a possible – some use cases may expect a DID to be persistent, a DIDs ability to continue to identify the same subject is a function of…
… the persistence of a DID depends on DID Method infrastructure – first suggestion.
… second suggestion, seems like this note should go in security considerations section.

Drummond Reed: Shigeya was recommending something to that effect.

Justin Richer: +1 to security or privacy considerations section

Manu Sporny: Im trying to hear what joe and drummond are saying, I think it may come down to a default way of thinking about dids and there are two ways being discussed right now 1) dids are permanent (bound permanent) 2) dids are ephemeral
… we can do a lot of variations between these two
… If I am understanding joe correctly, he is trying to ask what is the default model we should be thinking e.g permanent or ephemeral
… the difference here is in the assumptions around the binding for example do you get to assume without checking a did is continually bound to one subject

Brent Zundel: possible new first line text: “Some use cases may expect a DID to be persistent. However, a DID’s ability to …”

Markus Sabadello: A bit surprised permanence and persistence is so negative and harmful – in beginning, intention was – DIDs are persistent in sense that they cannot be taken away from you unlike domain names.

Brent Zundel: +1 to markus

Markus Sabadello: It’s an identifier that no one can take away from you
… Maybe what we forgot to point out was that you yourself could do that – controller could change persistence and permanence – this is what drummond might be clarifying with his PR.
… Positive aspect to Drummond’s PR.

Justin Richer: The best way to frame this, suggestion to moving to security/privacy – might be in dealing not with nature of technology itself, but the problems come from correlation which happens next to the technology.
… It’s not that a DID identifier is the same person over time, as much as it’s “this specific person” and “I can figure out who that specific person is” – even on impermanent systems, timebox and correlate to external party – I can figure out who it is.
… I like moving it down to considerations and promoting it out of a NOTE – hopefully in order to bring it up in an external context.

Christopher Allen: I guess I feel like we’re conflating a number of different things - I like Markus’ point, persistence – it couldn’t be taken away from you for as long as you want it.
… Worried that single word “persistence” has issue since it goes over multiple things.
… Permanently bound to a subject, having that be the default assumption kinda scares me on a number of levels.
… Especially when one of those subjects might be a person - DID initially about a service… well no, now is about person who has control over service… well, no it’s the heir that inherited it… and then ultimately, there isn’t a subject.
… “Bound to subject” sounds permanent, which I also don’t like.

Drummond Reed: I want to reinforce, although manu characterized it as “DIDs are permanent” – we did start there, that’s no longer true – I tried to clarify that – even if DID Controller wanted it to be permanent, that DID Method might not support that.
… I’m definitely convinced it should go to security considerations.
… I’m taking notes – one of the primary needs for URNs, reference in security architecture are to same subject… one of the challenges, URN community has always acknowledged, RFC8141 to acknowledge no technical way to ensure permanence… global uniqueness, no technical way to maintain the binding, always the operational and dependent on policies of different parties.
… I’m no longer saying “persistence is default assumption” – it is important to say “architecture supports” – if you need persistence – choose a method that supports it… or if you don’t want that, that’s fine too.
… Policy should be keep checking on the binding, but if you want a policy in place – did is permanent – architecture/ecosystem where things don’t change – you can program that they’re not going to change/assume they don’t change.

Jonathan Holt: I can see the dilemma on both sides - but mostly siding w/ Joe – concern is w/ correlation and use for nefarious purposes – persistence of the DID, same identity over same time – function of DID Controller, not their policies… cross check association is function of Verifiable Credentials tying together different attributes/identifiers/assertions/credentials.
… What this is trying to do is make the association at DID to DID Subject risky – for example, w/ my kids – have @me.com email addresses – but I was controller, but they are the DID Subject, but that DID Subject may change over time.

Tobias Looker: Just a quick note - in general, we’re using persistence almost interchangeably even though to me they mean different things… Persistence and permanence of something, an identifier vs. a binding… which is identifier binding to abstract subject.

Jonathan Holt: +1 to tplooker

Tobias Looker: The language around the binding is problematic, drummond your point that update to RFC that you cited, essentially infeasible to guarantee persistence over time… we shouldn’t say that’s possible, we should scope this about persistence of identifier itself rather than around the binding.

Joe Andrieu: I like how Manu phrased the discussion, I think he captured the essence of it – I’m concerned about the language Drummond is using… I would posit there is not DID Method that provides proof of control and permanance with out biometric (fingerprint, DNA, etc.).

Jonathan Holt: +1 to JoeAndrieu, the assumption of the policy is the problem

Joe Andrieu: Drummond is saying if you have a policy in place where you can assume permanence, that is the issue.

Grant Noble: DID once exposed is undeletable, like Christopher, I’d like the ability to share things w/ people that are more permanent than others, saying that the thing is persistent kinda gets in the way of my controlling it.

Kyle Den Hartog: One of the things I think that is important to consider is guarantees we’re providing to relying parties – that’s where what Joe is articulating, consistent checking coming into play – VC is consistently checked whether it’s been revoked, signature is still valid, etc.
… VCs in offline, not possible to actually verify these things – at time of verification, at time of reception – what it’s stating in VC – when verifier takes it on as a risk.
… concept can be mapped to DID and DID Controller – binding of identifier, some level of trust w/ DID Controller for that situation, in some cases, they want the binding, in other cases they don’t.
… It comes down to not setting it, but allowing trade-off to make decision.

Manu Sporny: i wanted to point out that I think there is more alignment here
… no one things any use case is off the table by this language?

Kyle Den Hartog: to address manu’s point

Drummond Reed: One other high level remark – it feels like I need to remind folks w/ different perspectives that DIDs are not just for people, maybe it’s for a particular use cases, uniformly, there are a class of subjects that need to be identified that are not people, constant requirement is identification of a legal entity that will only be used for that legal entity ever.
… I don’t think anyone here thinks there shouldn’t be URNs.

Jonathan Holt: manu: I would say that use-cases aside, this is really about security and privacy concerns about making assumptions about the policy

Tobias Looker: To me the key to that use case is in how the assignment is done, which is often outside the scope of the identifier directly
… Therefore the binding is external to the identifier

Drummond Reed: It’s important to keep in mind, those cases – not an advocate for persistent things – except for peer dids, I don’t have to change it because I don’t control it – if there is no person there, no problem – policy-based things like registries – we’re trying to point out the ends of the spectrum, pay attention.

Joe Andrieu: The examples Drummond just gave are centralized and shouldn’t shape the spec, if you can achieve them w/ DIDs, that’s fine… but forcing that shouldn’t be how we frame this.

Jonathan Holt: +1 to JoeAndrieu, agree the use-cases presented are centralized and don’t have as much of a role in a decentralized world.

Joe Andrieu: 1. Remove language about permanent binding

Joe Andrieu: 2. Clarify how contextual correlation can be used, when appropriate

Drummond Reed: Joe, the notes didn’t capture your second suggestion

Kyle Den Hartog: I was under assumption that by removing language, we were removing mental model of use cases – just wanted to clarify - do you see ability to have persitent identifiers as sometihng we’re trying to remove, or is it going ot happen no matter what?

Drummond Reed: I don’t see it as either one – if controller wants persistence, what they need to pay attention to – that’s what I think we’re trying to answer… if we put it in security considerations, that’ll help.
… Thanks to all for input around subject, will try to turn this around in 48 hours.

Manu Sporny: just a request to joe, can you do a PR then we can review these side-by-side

Jonathan Holt: Is there an example of these “binding policies”?
… I haven’t seen that before.

Drummond Reed: I will just reference the URN RFC - we can just point to that guidance… for operations infrastructure for persistent identifiers.
… I was trying to pull out any mention of policies.

Jonathan Holt: The challenge is that they have a different role for centralized identifiers vs. decentralized identifiers… URNs might not apply.

Justin Richer: URNs are very much not centralized…

Justin Richer: just for the record

Brent Zundel: Thanks for conversation/feedback, thanks for all working on PRs – you guys are fantastic, a pleasure working with you! :)