DID Working Group Telco — Minutes

Date: 2019-12-10

Attendees

Present: Chris Winczewski, Ivan Herman, Amy Guy, Yancy Ribbens, Justin Richer, Brent Zundel, Manu Sporny, Orie Steele, Dave Longley, Michael Jones, Adrian Gropper, oliver terbu, Drummond Reed, Joe Andrieu, Irene Adamski, Markus Sabadello, Ted Thibodeau Jr, Jonathan Holt, Ganesh Annan, Kim Duffy, Daniel Burnett, Dmitri Zagidulin, David Ezell, Samuel Smith

Regrets: Phil Archer, Tzviya Siegman

Guests:

Chair: Brent Zundel

Scribe(s): Manu Sporny, Drummond Reed

Brent Zundel: Welcome, agenda review.
… We invite you to join IRC, that’s where the official record happens. For side conversations use /me THING_YOU_SAY
… q+ if you have something you’d like to add… q+ to THING_YOU_WANT_TO_SAY for reminder.
… we’re going to start off w/ a PSA on scribing… then F2F activity… time boxed matrix parameter discussion, then created property.
… Any additions to agenda?
… None, moving on.

1. Introductions

Brent Zundel: Anyone joining the call for the first time?

Irene Adamski: Yes, hello.

Irene Adamski: Hello, Irene, joining on behalf of Jolocom, already a W3C Member, I will be here to soak it all in, wanting to actively contribute, Honor to be here, looking forward to getting to know all of you, based in Berlin.

Brent Zundel: Anyone else want to introduce themselves?

Ted Thibodeau Jr: Hi, Ted Thibodeau with OpenLink Software, joined W3C 2001-ish. Since the early days of WebID, we’ve recognized this is an important piece of distributed computing, happy to be here.

Daniel Buchner: After thinking a lot about the Matrix param discussion last week, and the realization that Matrix params actually make an ID with a param into a new ID, I don’t thing they’re hardly as useful

2. Contributing

Brent Zundel: There are many ways to contribute to the WG… some contribute via issues, discussion, unique viewpoints, reactions/responses on PRs, all valuable things.

Daniel Buchner: That behavior, adding a matrix param == a new ID, it’s just not useful for the vast majority of cases

Brent Zundel: One of the easiest and most valuable ways to contribute is to willingly scribe. Some consider it to be a really fun thing… some think it’s onerous.

Dave Longley: daniel: i do think their utility is much more limited than perhaps some people have thought

Daniel Buchner: So much so I think they should be removed from the spec

Daniel Buchner: so much complexity, for honestly is very little benefit

Brent Zundel: We encourage everyone to scribe. Yes, some can’t, but we do hope that all of you can contribute. Please be fully engaged, if you think that you don’t think scribing is important, please look deeply into your heart and reconsider. I encourage all of you to scribe. It is important.

Daniel Buchner: Orie had a good suggestion yesterday: add some sort of resolver param character to pass resolver only values

3. public key format

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

Manu Sporny: There’s been a long discussion around public key formats, happening in dedicated calls.
… this is a heads up that there is an intent to merge it, so this is a heads up

Daniel Buchner: like did:foo:123-456$initial-values=34534524

4. Face to Face Activity

Daniel Buchner: @markus_sabadello: Matrix params don’t work for the initial-values thing

Brent Zundel: We have an activity planned for our F2F.

Daniel Buchner: the implied difference in IDs is what nukes it

Brent Zundel: There is an attendees tab on the spreadsheet, please let us know if you’re coming.
… The boat tour is second day in the afternoon.
… Having a sponsor will make things simpler, we’re looking for a sponsor.
… We’d like to avoid figuring out the finances of it. If it doesn’t work out, people will just pay for their own tickets. Boat fee is €165 Euro, then €20 per person.
… If there are those of you that are willing and able to sponsor, reach out to Chairs.

Ivan Herman: https://boatamsterdam.com/cruises/premium-cruise/

Ivan Herman: There is the URL for the company I found, they gave me these prices, we’re talking 90 minutes with small private boat, limit of 22 people… if the group is bigger, then we have to figure out who gets to ride on a boat.
… The €8 extra per person includes a drink.

Daniel Buchner: for €200, I was thinking we’d each get our own keg

Ivan Herman: It’s January in Amsterdam, probably no sunshine, but there is a closed area on the boat.

Daniel Buchner: I once made a boat using kegs, so probably

Brent Zundel: Time boxed to 15 minutes. One of the Editors is going to guide us through this.

Daniel Buchner: ;)

Michael Jones: Manu, I request that you change RFC4648 to RFC7515 before merging, per my just-submitted review

Brent Zundel: Link to F2F Agenda Spreadsheet: https://docs.google.com/spreadsheets/d/11haGLiY3AYi8uxIQcfndAixmtXjymNTTFbDQWRYkKrQ/edit#gid=0

5. Matrix parameters

Brent Zundel: Matrix parameters: https://github.com/w3c/did-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+matrix

Markus Sabadello: This is a syntactical construct that’s a part of the spec. There are some matrix params in spec that are PRs that are open, others are in the spec. Since we had the last call, two of those PRs have been closed… key matrix param was closed.

Manu Sporny: selfissued, I will change that reference before merging.

Orie Steele: Example of their potential use by workday did method, as an id for a VC Schema: did:work:MDP8AsFhHzhwUvGNuYkX7T;id=06e126d1-fa44-4882-a243-1e326fbe21db;version=1.0

Markus Sabadello: The other one is to identify resources that are not a DID Document… there are more natural ways of doing that. Discussion is that when matrix parameters should be used and when they shouldn’t be used.

Dave Longley: Orie: i think that should just be a DID instead

Markus Sabadello: Summary - matrix parameters could make sense if you want a separate identifier for a separate resource, when you make it part of a URl, you get a new identifier you want to use as a hyperlink, as a part of a graph, you want to use URLs to identify things… encourage everyone to look at PRs open now.
… There are discussions about whether matrix parameters are needed at all, if you want to remove matrix parameters, maybe open an issue (because they’re in the spec now).

Dave Longley: (i.e., just make another DID and the subject is the schema)

Markus Sabadello: The CCG made the decision that matrix params were useful. If we want to have a discussion about whether or not we want them, we need to do that in a separate issue.

Orie Steele: dlongley: I don’t disagree… we had a long debate in Aries around not doing this kind of thing for aries specs, and ended up using https instead…

Dave Longley: yup https works too

Daniel Buchner: I’ve spent some time thinking about matrix params… didn’t realize that when you add any matrix parameter, you fundamentally change the DID, it’s not the same identifier. I can’t see how that’s useful in the vast majority of use cases.
… so initial parameters don’t help… trying to get some clarity, so if it means DID changes then that’s less useful, looking for clarity there.

Markus Sabadello: It doesn’t change the DID, but it is a new DID URL… DID URL under same authority, what it identifies needs to be specified by matrix parameter.
… For example, if you use it to identify a service endpoint, you’re not talking about the DID subject anymore.
… if you use version, then you’re talking about a DID Document at a specific point in time.
… For example, when would you make something part of an HTTP URL, or when would you add it as an HTTP Header.

Orie Steele: So it sounds possible to make a matrix parameter that identifies the did subject… where the long form, is understood to be the short form.

Daniel Buchner: If I add a matrix parameter, what happens to original DID?

Daniel Buchner: orie: so we were mistaken, i assume?

Markus Sabadello: You can set a matrix parameter in a way that doesn’t identify a different person/thing.

Orie Steele: daniel: not clear at all!

Daniel Buchner: meaning, it is again OK to use them for what we need?

Orie Steele: its not clear…

Michael Jones: I’m enlightened by discussion on matrix parameters last week, this was an invention from 25 years ago that didn’t see adoption and wasn’t viewed as necessary or useful… yes, I’m raising the question on whether or not we should have matrix parameters. This is a fundamental change with Web architecture and we should go in with eyes wide open.

Daniel Buchner: based on what Markus said, it would seem so

Michael Jones: We have query parameters and fragments… before we decide we have to change web addressing, we should think about encoding things in the proper way.

Brent Zundel: Markus did say that if you want to have that conversation, raise that issue.

Markus Sabadello: +1 to brent, raise an issue if you want to discuss matrix parameters in general (rather than discussing a specific matrix parameter)

Dave Longley: I agree with Mike, but I do want them to know where the conversation started. It started from place of where matrix parameters started, we didn’t have a way to construct a URL that didn’t impact query parameters and fragments.
… A DID is used to resolve DID to get DID Document. If you have a matrix parameter in it, the only time you want to use a matrix parameter is when you’re trying to refer to something and you can’t use anything else… like no query or fragment. Refer to external resource relative to DID subject via some content in DID Document, past version, or talking about identifying resource that you go through DID Doc to find endpoint to go to server to find resource.

Daniel Buchner: So are folks on here still fine with adding a regular URL param to the end of a DID?

Daniel Buchner: did:foo:123-456?initial-values=34w5445vw45gv4wv

Daniel Buchner: ^ ?

Dave Longley: It lets you create a stable URL based on servers moving locations… you want to move the end resource around, so you can port data from server A to server B but keep stable identifier for resource… that was main canonical use case.

Daniel Burnett: +1 to service endpoint use case, -1 to most others. dlongley is correct that service endpoint was the initiating use case for matrix params.

Dave Longley: That resource may need to have query, hash, and that kind of stuff… those things need to be opaque, which is why we need matrix parameters.

Drummond Reed: Wanted to reinforce, having worked on these things, answer to mike’s question – there is a very specific reason we chose matrix parameters and syntax… it was to leave the path, query, and fragment components completely open to developers to use in any way.

Daniel Buchner: Seriously though, I just need to tack some crap on to the end of a DID string to allow a resolver to resolve a DID Doc that has not yet propagated, or the current Doc, if it’s after the initial publication

Drummond Reed: The use of a service endpoint to compose a result URL and be able to pass it path, query, fragment leaves open only one option to select the endpoint. Something that’s a part of the authority component of the URL, which means syntactically separate from DID.
… Yes, it’s an old construct, but because we’re creating a class of abstract identifier that doesn’t exist on the web today, that’s why we are discussing.

Chris Winczewski: Point of clarification. We are formally discussing https://github.com/w3c/did-core/issues/137 correct?

Manu Sporny: responding to @selfissued: Manu does not want to raise an issue to get rid of matrix parameters

Kim Duffy: late to the party but everything I’m hearing about matrix parameters gives me the gut reaction that these are non-standard and have design stink all over it. The use case of specifying down to a server sounds like “you’re doing something wrong”

Manu Sporny: because there is no other way to solve the problem for a set of use cases
… for example the ones that @dlongley and @drummond have explained, e.g., service endpoint selection or version selection

Markus Sabadello: Current list of PRs about matrix parameters: https://github.com/w3c/did-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+matrix+parameter

Brent Zundel: We do have an issue about matrix parameters, 137.

Michael Jones: In the interest of time, let’s not discuss here, but would like to have a discussion about query parameters and why we can’t use those.

6. meaning of “Created”

Brent Zundel: https://github.com/w3c/did-core/pull/28

Drummond Reed: @selfissued RE the authority component, we have full rights to add syntax there in the DID URI scheme, but not in query parameters

Manu Sporny: https://github.com/w3c/did-core/issues/65

Manu Sporny: wants to try to focus the discussion on what we should talk about in this WG
… there are 3 aspects. The first one is when the DID document was created an updated.
… that topic is being debated in the resolution subgroup that @markus_sabadello is leading
… so the other options are: 1) an assertion on the ledger itself about when the DID document was created/issued

Dmitri Zagidulin: there is already a field for ‘the ledger is asserting the creation date’, separate from ‘created’

Manu Sporny: and 2) the DID subject’s assertion of when the DID document was created/updated

Dmitri Zagidulin: so we’re only talking about 2

Manu Sporny: manu believes that it is the latter

Dave Longley: wouldn’t it be when the DID subject was created?

Oliver Terbu: We should also consider that some did methods do not have an easy way to assert created/updated time

Dmitri Zagidulin: we are not talking about the ‘ledger is asserting the DID was created’ date, because that’s a different parameter
… so the DID document contains: 1) the DID, 2) DID metadata, 3) resolution metadata

Jonathan Holt: For specific DID methods, you must refer to the ledger, so the only option is the author’s assertion

Markus Sabadello: Notes that “created” and “updated” correspond to two operations required by a DID method
… so it’s okay that the DID document contains the author-asserted timestamps and resolution produces the DID registry-based timestamps

Joe Andrieu: wants to comment on terminology

Oliver Terbu: some did methods are not ledger-based but there are some did methods such as did:ethr that are ledger-based but don’t require a ledger to be created. so, no information can be put into the did document for the creation time.

Dave Longley: agree with Joe … a DID document is controlled by a DID controller and says things about the DID subject

Joe Andrieu: it’s not the “DID subject” that sets the date, it’s the “DID controller”

Markus Sabadello: +1 to JoeAndrieu , we should have all said controller instead of subject

Joe Andrieu: wants to make sure we’re using the right language

Brent Zundel: seeing wide agreement that the datestamps in the DID document are asserted by the DID controller

Jonathan Holt: probably even more specific would be the DID controller software

Manu Sporny: agrees with Joe on terminology
… so the question is: security issues around using datestamps asserted by the DID controller
… so Manu would like to understand why self-asserted datestamps are important

Brent Zundel: so this moves us to the topic that if dates are DID-controller-asserted, are they needed?

Dave Longley: If the timestamps are in a DID document, they should be authoritative.

Ivan Herman: +1 to dlongley

Orie Steele: +1 to dlongley

Dave Longley: so they should be describing the DID subject, not the DID document

Oliver Terbu: -1

Dave Longley: “DID subject createdDocument date” would make more sense

Dave Longley: but still messy.

Dmitri Zagidulin: the name of the property is ambiguous, so the proposal is to change it to didDocumentCreated and didDocumentUpdated

Orie Steele: why?

Brent Zundel: so the question is now whether this is needed

Oliver Terbu: -1 because some ppl don’t create the did document at the created time

Orie Steele: what is the use case for knowing when the document was created, by looking at the document?

Oliver Terbu: some did methods don’t store the did doc on a ledger

Dmitri Zagidulin: oliver - I’m not sure I understand

Dmitri Zagidulin: oliver - the timestamp is not about the ledger. it’s only about when the document was created (the ‘created on the ledger’ or whatever is a separate field)

Jonathan Holt: asks if PGP keys in the web-of-trust are self-asserted with regard to datestamps?

Brent Zundel: is anyone a PGP key expert that can weigh in?

Orie Steele: I’m not sure anything PGP does regarding embedding meta data like this is good.

Brent Zundel: brent has only been to one PGP key party

Jonathan Holt: looking at his own PGP keys, he attests to their datestamps, so he wants to get the same info about others

Manu Sporny: PGP does allow you to assert datastamps for keys, but that does not make for good security

Orie Steele: +1 to manu, there is no solid use case.

Oliver Terbu: dmitriz - let’s have this discussion in a github issue

Daniel Buchner: Seems like added complexity for little benefit

Samuel Smith: q

Yancy Ribbens: +1 to manu

Manu Sporny: but we are not hearing a solid use case on why we would need “createdDocument” and “updatedDocument” as asserted by the DID controller

Daniel Buchner: one can make an argument for throwing tons of things in the docs, I think we should be super stingy about it

Jonathan Holt: can look at his own keys and the timestamps associated with each
… even though it is self-asserted timestamp, it is still a way of keeping order

Daniel Buchner: why can’t you save them with an added stamp post resolution, when you save it to your machine

Manu Sporny: agree with daniel – we should be very careful about the data we standardize in DID Document.

Dave Longley: agree with daniel/manu so far.

Samuel Smith: from a security perspective, the only way the DID controller can make an authoritative assertion about the DID document is to link it to a hash of the event that existed at that point in time
… any other ordering can be self-asserted, forged, etc.
… so that would be the cryptographic way of verifying the authoritative ordering

Yancy Ribbens: blockheight can determine time ordering?

Dave Longley: what is “authoritative” is up to the DID method, but agree we should be using crypto here to extend trust

Dave Longley: (when we can)

Manu Sporny: agrees with Sam. If a createdDocument property is in the DID document, it needs to be cryptographically verifiable

Orie Steele: you can always just embed a PGP key in your did document which contains this (and other) meta data.

Dave Longley: +1 to Orie

Joe Andrieu: @orie that would only cover the key, not the entire document

Dmitri Zagidulin: I’m totally fine with pushing down the ‘documentCreated’ metadata field down to method-specific land.

Manu Sporny: the case of just self-assertion of metadata about a DID document for the author can be handled in other ways

Yancy Ribbens: +1 to metadata not going in diddoc

Manu Sporny: but all of those ways are outside of a DID document

Daniel Buchner: or use Epoc seconds as your IDs in the values

Manu Sporny: so Manu is not hearing a strong use case for having these properties in a DID document

Daniel Buchner: epoch*

Manu Sporny: and believes we should take them out of the spec until there is a strong use case

Dave Longley: if you want to express when you registered a DID with some registry – you can add that to your DID doc perhaps under a “registration” property with more information about what you registered … i would think if you have anchored your DID to other blockchains you’d want something like that anyway for more than just one ledger/blockchain

Manu Sporny: daniel, yes, that would be a fine thing to do… epoch in id itself, and hopefully, asserted by the ledger.

Dmitri Zagidulin: dlongley: there’s a separate field for when it was registered, tho

Joe Andrieu: believes that it’s too early to call for lack of use cases when the conversation is just getting started

Dave Longley: dmitriz: this is about the DID controller saying something

Joe Andrieu: there are lots of examples of claims that are not directly tied to the subject

Daniel Buchner: The DID controller saying something is not substrate-authoritative

Joe Andrieu: this is the only place where the DID controller can assert these properties for purposes of redundancy and sniff tests

Orie Steele: SamSmith this is an attempt to formalize inception event

Dave Longley: so it seems the cases here are entirely around self-assertion, in which case such an “anchor” should have

Daniel Buchner: it’s speculative data, not something remotely falsifiable

Dave Longley: semantics that make it clear that its self-asserted info from the DID controller

Joe Andrieu: +1 to more specific property

Manu Sporny: +1 to daniel

Irene Adamski: @manu: unrelated to current discussion - who can I contact about more infos on the f2f in Amsterdam?

Justin Richer: the fundamental question is whether the DID document should be internally self-describing

Daniel Buchner: If it’s just an assertion by a party external to the trust-minimizing anchoring system, then there’s 0 reason we can’t make that a separate witness statement outside of the doc

Dmitri Zagidulin: great way to put it, Justin

Justin Richer: there are others seeing the DID document will be in a context that has other metadata about it

Daniel Buchner: if you want it bound to a doc revision, we could just allow a single prop for witness data that can be included via hash reference

Justin Richer: so these two views need to be reconciled

Dmitri Zagidulin: agrees with Justin_R

Joe Andrieu: @daniel, it’s a statement by the controller, just like everything else in the DID Document. All of which lack falsifiability.

Daniel Buchner: That way you can stuff a freaking DVD worth of witness data in there if you want, just via hash link

Dmitri Zagidulin: Dmitri believes that DID documents need to be self-describing
… but if it is self-asserted, then it can be kicked down to DID method specs

Daniel Buchner: Can someone argue against the hash-link approach?

Dmitri Zagidulin: (also standalone, yes! has implications on portability / exportability of the DID)

Jonathan Holt: conflating the need for a DID registry to add the security around the created or updated timestamp is a different issue

Dave Longley: a DID document has information about the DID subject … if there will be “self-describing” information, then the DID controller should state that the DID subject has a DID Document with properties X, Y, Z.

Jonathan Holt: but for a DID document to be able to standalone and self-describing is still important
… there is probably a room for a compromise, where the property is optional

Daniel Buchner: { witness: HASH_OF_N_OTHER_FIELDS/DATA }

Jonathan Holt: what jonathan currently does is using Open Timestamps
… so thinks there is room to compromise

Samuel Smith: +1 to self describing. The DID Controller needs to be able to make authoritative statements in the DID Doc. But I think that it may be method specific

Dmitri Zagidulin: +1 to manu’s proposal.

Joe Andrieu: -1

Dave Longley: we should remember that the root subject of the DID document is the DID subject

Manu Sporny: to speak to that compromise, he proposes to take it out of the core DID spec, and let method specs decide about how to use it

Yancy Ribbens: +1

Daniel Buchner: +42

Dmitri Zagidulin: daniel - that’s + too many :)

Manu Sporny: however there is already dissent, so no action on that proposal yet

Dave Longley: so something must say “DID subject has a DID document”, and introduce a new object with properties about that DID document.

Brent Zundel: closes the call with thanks to the scribes

Dave Longley: (so there’s no confusion over what the properties apply to DID subject vs. DID doc)

Brent Zundel: remind that we won’t hold the call on Dec 25 or 31.