DID Working Group Telco — Minutes

Date: 2019-11-19

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Ivan Herman, Ganesh Annan, Manu Sporny, Dave Longley, Yancy Ribbens, Phil Archer, Amy Guy, Kenneth Ebert, Ted Thibodeau Jr, Daniel Burnett, Dmitri Zagidulin, chris mitre, Joe Andrieu, Jonathan Holt, oliver terbu, Kyle Den Hartog, Markus Sabadello

Regrets:

Guests: joel, tom, sumita

Chair: Brent Zundel

Scribe(s): Amy Guy

Content:

Brent Zundel: outline agenda
… anyone want anything else on the agenda?

1. introductions

Brent Zundel: tom, please tell us who you are
… tom is getting kicked off the call if no intro

tom: from USAA

2. face to face social activity

Brent Zundel: we planned 3 days for the f2f so we could spend half a day doing some ‘mandatory fun’ (not negative)
… an opportunity for us to get to know one another
… such activities can significantly improve the cohesiveness of our group
… is there anyone who would be willing to name themselves as planner of a social activity in amsterdam?
… best time would be the afternoon of the second day

Daniel Burnett: We do very much want people to attend. Social time with the WG is quite important.

Daniel Burnett: Ivan may be able to help with ideas

Ivan Herman: it is a bit unfortunate because part of the year I live in Amsterdam, but then I will not be
… one thing I looked up if someone can help is to have a boat tour on the canals of Amsterdam

Daniel Burnett: +1 boat tour

Daniel Burnett: on a closed boat

Ivan Herman: it’s a very pleasant thing to do, I know where we can get seats on a small boat
… it’s about 20 eur/pp
… I can make a phone call closer to the time but I cannot be there to check it, I arrive to Amsterdam at the same time as the rest of the group
… mike is not here, maybe some people at microsoft can help for the details
… that’s the only idea I came up with. In January is not the ideal time for Amsterdam due to the weather.

Ivan Herman: See the boat tour company I found

Ivan Herman: See another possible boat company I know

Ivan Herman: See Tripadvisor’s list

Brent Zundel: anyone in the group willing to take ivan’s boat tour idea and run with it or do some other option seeking?
… the chairs will continue reaching out, this is important

3. Next key format call

Brent Zundel: a doodle went out
… It will be Monday Nov 25th 3pm Eastern Time
… ivan, if you can get us a webex connection for an hour that would be wonderful

Ivan Herman: of course

Brent Zundel: that’s an optional call, but official for members, interested in moving that discussion forward

4. use cases and requirements fpwd note

Phil Archer: See UCR candidate FPWD

Brent Zundel: you all should have received an email with a link to the proposed fpwd of this note

Manu Sporny: +1 to publish as is…

Brent Zundel: we have five minutes to hopefully discuss whatever we might need to but the goal of this conversation is to end with a resolution to publish unless there are objections
… queue up if you would like to add anything

Dave Longley: +1 to publish

Ivan Herman: +1

Phil Archer: +1

Ivan Herman: before we make a final resolution, a practicality. Two ways of publishing this, we have to decide
… one is we publish a WD, like we do for a rec, even if it’s clearly saying that it’s not going to become a rec, then at some point in time we publish it as a note
… the other possibility is we publish a note now which we can update whenever we want
… it has a different feel to it if you do one or the other, I’m not saying we should do either one in particular, we have a choice and need a clear decision

Phil Archer: I would say draft because Joe and I have put lots of places in where we say finished or more to come
… in particular an area we need to add more content is a section for short use cases. there’s a section of more expanded use cases that has been around for a long time, from the CCG
… but there is a call for more people to provide us with short use cases and without that document is lacking
… there are open issues that we need to point to it being a draft
… and content yet to be provided

Daniel Burnett: +0.000001 draft

Phil Archer: I prefer something that says this is a draft

Manu Sporny: are we going to use echidna if the proposal is to do a draft?

Ivan Herman: personally I defer to the editors on the best way to publish
… Echidna, yes, as soon as we have the fpwd published, we can’t use echidna for the first round. Then we can set it up

Joe Andrieu: yes. A draft was our expectation.

Ivan Herman: if we take the resolution it should also say that editors want to use echidna

Brent Zundel: typing proposal

Joe Andrieu: we should also figure out the publication date

Ivan Herman: yes
… we have to submit a request for first public draft, I can do it tomorrow, will take a few days, we could aim for the 26th but it doesn’t depend on me
… I would say the 28th that’s probably very safe. I know it’s US thanksgiving but our webmaster is on the island of Réunion not in the US

Joe Andrieu: that language sent up red flags about, we still need to have the group chime in if it’s not editorial

Brent Zundel: any updates to the draft of the note would come through PRs that get discussed by the group

Proposed resolution: The DID WG will publish the current Use Cases and Requirements document as a FPWD of the Note, with a publication date of November 28, 2019. Subsequent WDs will be published automatically using Echidna as the editors see fit, following standard group discussion of any PRs. (Brent Zundel)

Manu Sporny: +1

Ivan Herman: +1

Ted Thibodeau Jr: +1

Joe Andrieu: +1

Phil Archer: +1

Markus Sabadello: +1

chris mitre: +1

Amy Guy: +1

Dmitri Zagidulin: +1

Yancy Ribbens: +1

Kenneth Ebert: +1

Brent Zundel: any objections?

Kyle Den Hartog: +1

Dave Longley: +1

Resolution #1: The DID WG will publish the current Use Cases and Requirements document as a FPWD of the Note, with a publication date of November 28, 2019. Subsequent WDs will be published automatically using Echidna as the editors see fit, following standard group discussion of any PRs.

Phil Archer: I’m very keen to hear more use cases. they don’t need to be long
… particularly ones that are not American
… this group is dominated by the US
… some are weird American only things
… short, brief are good

Joe Andrieu: in addition to non-US use cases it would be great to see ones that flesh out some of the requirements that drive some of the technical advocacy
… we don’t have use case coverage for all of the examples brought up in the key conversations
… the focal ones were written a while ago
… we don’t have coverage on all the things we want to make happen

Brent Zundel: we definitely have more work to do, appreciate the editors helping us to move forward

5. DID metadata

Brent Zundel: https://github.com/w3c/did-core/issues/65

Markus Sabadello: this issue is about the question of having data in the DID document some of which is about the subject and some of which is about the DID document itself
… there were ideas to maybe remove some properties like created or updated
… or proof property. That’s where this discussion started
… we thought created, updated, proof is it about the subject or the DID document itself
… dmitriz wrote a really good summary
… The question that we need to agree on is are we okay with data that is sometimes about the subject and sometimes about the document
… or do we want to separate that somehow
… I think there’s a third category which is data about a the resolution process, some metadata may be added about that in the result
… but the primary question is are we fine having data about the did subject like services an dpublic keys
… as well as about the document like proof
… and if we’re not, do the subject and the document have separate identifiers?
… we spent a lot of time discussing that
… we felt we are comfortable with combining that, they don’t need separate identifiers
… the same identifier for the subject and the did document

Manu Sporny: https://github.com/w3c/did-core/pull/27

Manu Sporny: https://github.com/w3c/did-core/pull/28

Manu Sporny: I want to point out that we have two PRs pending, 27 and 28, when I put those PRs in there my assumption was that the created and updated were being used to describe metadata about the DID document
… but after putting it in I can see how people thought they were about the DID itself, the identifier
… this is really a metadata discussion, if created and updated are truly about the identifier itself and not metadata about the DID document then it’s fine to keep them in there
… but if is metadata about the DID document I feel strongly we should take it out, we shouldn’t be conflating those two things
… we need to decide whether or not it’s okay to use the same identifier to kind of sort of refer to two different things

Ivan Herman: +1 to manu

Manu Sporny: that is a huge red flag in the linked data space, your semantics get really messy
… similarly you do not need to have an identifier for everything
… you can do autogenerated identifiers, that’s a common thing, we use it in VCs
… we could have metadata about the DID document that’s outside of the DID document itself, much cleaner separation

Daniel Burnett: The DID document is not the resource. It is an explicit representation of access mechanisms (to use the HTTP URI analogy)

Manu Sporny: if we come to that philosophy it’s much easier for us to determine if a particular item is in or outside of the DID document
… I thought the original issue was about metadata about the DID document, interested to see if anyone hears differently

Jonathan Holt: I thought these were for convenience, and if you wanted to find the original source of truth you spin up a resolver or your own node and verify the assertions being made in the DID document

Manu Sporny: I’m hearing Jonathan say “issued” and “created” are about the DID Document.

Jonathan Holt: my interpretation was they were self asserted related to creation of the DID document, and are there for convenience
… what markus mentioned for identifiers, the keys ed25519, hiding keys.. was that what you were talking about as far as the subjec tidentifier? you have to have a self asserted key identifier in the DID document that’s only about its own keys?
… or are we having this conceptual framework of referring to delegate keys or controller keys?
… what are the semantics we are working with?

Markus Sabadello: we’re not talking about identifiers for keys, we’re talking about whether the DID is an identifier for the subject, that’s where we ended up after a few months of httpRange-14, or is the DID the identifier for the document, or is it both?
… I think the community thinks it should be both
… but understand that’s ambiguous from a linked data perspective

Jonathan Holt: the subject is the identifier around the DID document, not a human subject?

Markus Sabadello: the DID subject is the person, org, thing, whatever, resource, identified by the DID

Daniel Burnett: “The DID subject is the subject of the DID.” <- Official definition :)

Dmitri Zagidulin: interpretation about created, updated, my summary in issue 65, I was interpreting them to be metadata about the DID document
… I’m not sure it makes sense to have metadata abut the DID because it doesn’t apply separately to the DID document

Markus Sabadello: +1 to dmitriz that created, updated are metadata about the DID document

Dmitri Zagidulin: On the issue of does metadata about the document belong there. On which grounds is manu objecting?
… I laid out several arguments that i’ve seen you make in the various issues against it, which are relevant and howd o you feel about the counterpoints?

Joe Andrieu: I’ve flipflopped on this issue
… one aha for me right now is the definitive way to find out if a given DID document is the correct DID document for a given DID is to execute the resolution process

Daniel Burnett: markus_sabadello, does created not apply to BTCR DIDs where DID documents are generated rather than stored?

Joe Andrieu: If that’s correct, there’s not necessarily a baked in way for a document to demonstrate on its own as a set of bytes that it’s the authoritative one, I think whatever metadata you need to verify the process needs to be in the DID document
… otherwise that separation feels a little false to me

Manu Sporny: there is a certain subset of things I’m strongly objecting to, and that’s the conflation of any kind of semantics
… it’s not clear to me what the group things issued, attributed, means yet
… one thing that might be helpful, there are two categories of information we are talking about
… information about the identifier itself, the DID string, and whatever it may identify
… and then information about the DID document itself
… those are two distinct categories that i think we should keep distinct
… if we conflate them there’s nasty stuff that can happen
… that’s where my concern comes from
… Let’s say that we say that updated is the time the identifier was updated. Semantically that’s meaningless. I know the identifier was updated but it doesn’t tell me anything more than that
… whereas if the DID document was updated, there’s a change the resolver can check, that’s about the document itself not the identifier. The semantics are very different

Dmitri Zagidulin: nobody is proposing that it would be about the identifier

Manu Sporny: i’m not convinced
… I think some people are and some people aren’t, and some people don’t understand what conflating those two things does to the entire data model
… You may not be proposing that and I think other people might be, we need to get down to the definition of what created and updated really means to people, and then see if those definitions are the problem

Dmitri Zagidulin: the topic of this issue is does metadata about the document belong in the document
… that’s a separate httpRange-14 discussion
… nobody is conflating, just discussing whether data about the document belongs in the document

Ted Thibodeau Jr: “How do we identify the identifier which identifies an entity?”

Dmitri Zagidulin: Having metadata about the DID document in the document allows portability
… it allows fo standardizing of that metadata among mutable DID methods that don’t have underlying ledger mechanisms

Markus Sabadello: manu is saying sometimes we’re talking about metadata about the identifier, I don’t think that makes much sense
… it always identifies something, and the data is about that resource
… we can’t have data about the identifier, we can only have data about the thing being identified
… with data about the subject, data about the DID document
… I agree it’s better to separate them, even though conflating was the outcome of a few months of discussion of httpRange-14, makes more sense to keep separate
… agree with dmitriz that the metadata about the document inside the DID document is the issue. inside the DID document we need a separate object or level of JSON-LD structure
… one one level describe the document, on one about the subject

Dave Longley: when we’re talking about updating or applying an update to a DID document, eg. adding a key, we’re really updating the subject

Daniel Burnett: yes, explicitly marking any meta data as such by placing it in a separate subtree in the DID doc would at least make clear that it is different

Dave Longley: The predicates in a DID document are things like authorization, which the subject, some aspect of a person or some thing, and when you add a key you say this person authorizes this key for some purpose
… that’s the statement you’re making
… if you make that kind of update you’re updating information about the subject, not the document
… these update times that are metadata might actually be information about the subject not the DID document

Manu Sporny: I agree with dlongley, that’s the point I’m attempting to make.

Dave Longley: dmitri also brought up portability, we’re talking about porting information about the subject, not the document
… the information inside the DID document is about the DID subject. That’s what you’d want to port
… I think we disagree less than we think because a lot of these things we’re talking about are really just more information about the DID subject
… manu was talkign about the identifier, I think he really meant information about the subject not the DID, we’re not changing DIDs, that doesn’t make any sense
… a lot of the disagreements go away because we’re not talking about metadata that happens to live on some registry somewhere, we’re talking about the subject

Joe Andrieu: manu, you conflated the identifier with the subject. A lot of people have been responding in confusing because of that. I don’t think anyone is talking about putting information about the subject in a DID, that would be a privacy antipattern
… we have a did that’s a string, we don’t need metadata about that
… The subject.. the DID document is how you get from the DID to secure interaction with that subject
… We need to be much more careful about the language we use here, it’s confusing us, going to be more confusing for others
… we have this weird issue of the definitive DID document is not a string of bytes anywhere, it’s the output of a resolution process
… to understand if it’s definitive, whatever metadata we use, needs to be part of the DID document

Daniel Burnett: I wanted to bump up a level here
… the metal model that led to where we are
… as long as we can keep that mental model we’ll be fine
… what joe said matches what manu said
… we wanted our use of DIDs as URIs to work similarly to the way other URIs work
… such as http URIs
… if you look at the definition that we always refer to of a URI there is a resolution process and a dereferencing process
… the resolution process is where you discover what the access method and operation methods with the resource are, including any kinds of authn approaches that are necessary
… we’re different from http - we put a lot of that information that is part of the resolution process in the DID document
… we’re getting confused by making the DID document something more magical than it is intended to be
… which is a representation about how you access and update the resource
… it’s not the access to the resource itself , it is the things you can do with the resource and how you can authenticate yourself for that
… That may help. We may still decide that there is information that is not about the resource itself but we stil may put it inside the DID document
… joe is correct that conceptually the resource access methods all of this exists even for DID methods that do not explicitly store a representation of the DID document
… the DID document can be generate if necessary, not have to live at a location somewhere

Ivan Herman: from a linked data / semantic web point of view
… with JSON-LD for the did document, that means we define in a particular syntax a bunch of RDF triples and if I can imagine a linked data environment which includes lots of triples, includes the triples in the did document
… according to the JSON-LD and RDF, there are triples, and all what I see in the DID document. The triple consists of subject, predicate, object, and the subject is a DID URL
… that’s what happens in RDF

Manu Sporny: yep, to Ivan.

Ivan Herman: none of those triples have to say anything about the DID document itself because the DID document is just a collection of triples

Manu Sporny: exactly, Ivan.

Ivan Herman: if we want to say something about the DID document, we need another subject that identifies it, in order to play properly with the linked data world
… if you link it to any other process that wants to use these identifiers, we have to be careful because you will get wrong triples
… triples that say things you don’t want
… and someone may use those triples to deduce things that semweb technologies can deduce, you will get wrong statements, you cannot mix these two up

Brent Zundel: we have 9 mins left

Dmitri Zagidulin: to draw a parallel with the VC data model
… we had the same discussion about the created metadata, and there we have two separate sections, subgraphs
… one about the credential and the other about the credential subject
… we label it
… we standardized the created timestamp for the verifiable credential

Dave Longley: +1 to ivan, the DID Document is a graph/dataset with triples about the DID subject in it

Dmitri Zagidulin: this is the same thing that’s being proposed for the DID document
… we standardize it for the DID document, not to the person or org
… if we need to have a separate linked data section so that the triples don’t get confused, that’s fine, let’s talk about that

Ivan Herman: +1 to dmitriz

Dmitri Zagidulin: but I want to re-emphasize the need for storing the data about the document not the subject in the document itself

Joe Andrieu: the conversation isn’t about triples. it’s about quads. about statements about statements.

Dmitri Zagidulin: the counter that manu seems to be proposing is we let each did method standardize their own. That doesn’t seem right

Manu Sporny: dmitriz that is absolutely not what I’m suggesting
… I think there’s some miscommunication
… we need some concrete examples

Dmitri Zagidulin: let’s take ‘created’ as a concrete example.

Manu Sporny: The thing that you raised is spot on - in VC we had two subgraphs, one for the credential, the other for the credential subject
… this is the exact same thing
… the issue is that.. what we need is put some concrete examples and ways we could address this problem
… we can use created and issued as examples
… that would help people see how the philosophy applies to an actual concrete solution
… we only need two examples, there are two ways we can go
… that’s what we need for the next time we discuss this

Ivan Herman: +1 to manu, we need specific examples

Manu Sporny: people can see what’s being proposed

Joe Andrieu: +1 for specific examples
… The thing is we’re not talking about triples, we’re talking about quads

Kenneth Ebert: I like the examples, too

Joe Andrieu: I’m not familiar enough with JSON-LD spaghetti, methods for representing quads

Brent Zundel: +1 for examples

Joe Andrieu: we’re talking about the context in which the triples are stated

Dave Longley: {id: $MD_CODE$$MD_CODE$ means "the DID subject (identified by `, authentication: [`) has authorized `]}` for the purpose of authentication" ... that's a statement about the DID subject

Joe Andrieu: we need to make statements about that context
… we need to be able to in the DID document say something about the DID document
… metadata about the resolution is part of proof
… why do we believe this? here’s some metadata about the process to increase your confidence that this is legitimate
… What needs to be in there we should figure out at the DID document level, not at the DID resolution level

Markus Sabadello: +1 to keep the triples/quads clean and separate. Strictly speaking we would need a separate identifier for the DID document

Daniel Burnett: +1 dlongley

Manu Sporny: you don’t need to give the DID Document a separate identifier… can be a blank node… works just fine.

Markus Sabadello: the problem with that which we’ve discussed before for a few months, if we give the DID document a separate identifier we ran into problems defining the dereferencing process with URLs, especially if the DID URL has a fragment
… the way you dereference a fragment is you first deref the primary resource, without the fragment. The result has a mime type and dereferencing the fragment depends on the mime type

Ivan Herman: +1 to markus_sabadello

Markus Sabadello: if it’s an identifier for the subject, we can’t dereference it because it’s a real world resource and doesn’t have a mime type
… I like what dmitri said, parallel with VC, separate sections about the document and the subject

Dave Longley: a DID Document itself is much more ephemeral – you generally don’t “talk about it”, except perhaps to make statements in a resolution process

Brent Zundel: we had a recommendation to present real world examples so we can have something more concrete to discuss about
… The issue, 65 is assigned to markus

Manu Sporny: {resolution_things… didDocument: {did document things}}

Brent Zundel: markus, comfortable working to arrange some concrete examples?

Markus Sabadello: I can come up with some examples

Manu Sporny: {metadata_about_did_document… didDocument: {did_document_stuff}}

Daniel Burnett: yes, dlongley, this is what I meant by giving a DID document more reality than it should have, which is a physical representation of resolution info

Dave Longley: I think it helps to think of the DID Document as a graph … for which we generally don’t give an identifier

Ted Thibodeau Jr: DID document … is { .ttl owl:sameAs .jsonld owl:sameAs .rdfxml }? Can you speak of one serialization? Or only of all?

Ted Thibodeau Jr: It can be important to track when info about a subject was changed, as well as when the subject changed, as well as when the info about the subject was logged (which may be different from when it changes)…

Ted Thibodeau Jr: VERY complex!

6. meeting closure

Brent Zundel: great
… hopefully we’ll have those to refer to next time
… everyone continue this conversation in the issue itself and keep moving forward
… I’m going to wrap up the call, thanks everyone for coming
… Reminder - still looking for someone to host and someone to plan an activity during our f2f in Amsterdam
… Reminder - next week’s meeting will be at a different time
… happier for US and Asia pacific, afternoon eastern time
… 6pm eastern time next week
… Fin.

7. Resolutions