DID Working Group F2F, 1st day — Minutes

Date: 2020-01-29

See also the Agenda and the IRC Log

Attendees

Present: Manu Sporny, Samuel Smith, Brent Zundel, Daniel Burnett, Tobias Looker, Ganesh Annan, Michael Jones, Drummond Reed, Joe Andrieu, Kenneth Ebert, Yancy Ribbens, Yoshiaki Fukami, Christopher Allen, David Ezell, Kaliya Young, Oliver Terbu, Justin Richer, Ivan Herman, Markus Sabadello, Jonathan Holt, Eugeniu Rusu, Phil Archer, Amy Guy, Charles Cunningham, Joachim Lohkamp

Regrets:

Guests: Eric Welton, Oskar van Deventer, Carsten Stöcker, Michael Shea, Juan Caballero

Chair: Daniel Burnett, Brent Zundel

Scribe(s): Manu Sporny, Brent Zundel, Daniel Burnett, Joe Andrieu, Kenneth Ebert, Yancy Ribbens

Content:

Ivan Herman: Meeting slides: https://tinyurl.com/didwg-ams2020-slides

1. Welcome

Manu Sporny: brent is going over logistics.

Brent Zundel: We are in Spaces, Microsoft Schiphol (thank you Microsoft!)
… Dial in information has been sent out to the mailing list.
… We need to get dinner organized tonight. About 20 people raised their hands. Christopher will plan dinner.

Daniel Burnett: We will get a plan together for dinner by noon-ish.

Brent Zundel: IPR Policy - if you are a DID WG member, we look forward to your contributions. If you are observing, please refrain from making substantive contributions.

Eric Welton: I promise not to be substantive. laughing

Daniel Burnett: You can provide input on requirements, goals, etc… but not how to solve the problem.

Brent Zundel: Today’s agenda is here – https://docs.google.com/spreadsheets/d/11haGLiY3AYi8uxIQcfndAixmtXjymNTTFbDQWRYkKrQ/edit#gid=0
… We have introductions, thank you to Microsoft for the space, food, etc.
… We start the day with level setting, security issues, DID and IoT. Then a break.
… We will then talk about encodings and data models. Lunch. Then extensibility, break, then metadata and an open slot at the end of the day.
… we can talk about issues/PRs in open slots in agenda.
… This is a good time to learn how to scribe, please volunteer.
… Put your name on one of these boxes on Agenda if you want to scribe. Don’t scribe when you’re presenting.
… The scribing of the meeting is happening in IRC - on #did channel.

Daniel Burnett: Everyone needs to be on IRC.

Brent Zundel: If you have something to say, queue, present+, etc.
… We are going to introduce ourselves - your name, who you work for, single sentence why you’re here, what is your favorite programming language and why?

Daniel Burnett: Hi Dan Burnett, my favorite language is Oz - created for teaching, started with small primitives, then built from there - language can do just about anything you can think of, with a small set of primitives. Example on screen shows how easy it is to do multithreading.

Brent Zundel: Hi Brent Zundel, I work for Evernym. I’m here because I love DIDs, and I love the power of Self Sovereign Identity… my favorite language is ML - small functional programming language from Haskell. In grad school, I had to write a parser generator … everyone else was using C++, had to print out code because professor was a sadist… everyone else had 30-40 pages of code, my ML program was a page and a half.

Kenneth Ebert: Hi Ken Ebert, from Sovrin Foundation. I’m here because of focus on privacy. Favorite programming language is used for Karel the robot, great beginning programming language.

Tobias Looker: Hi Tobias Looker, from Mattr. Working on decentralized identifier tech - excited about new wave of technology for this standard. My favorite language is TypeScript or C# - from a syntax perspective, good static/dynamic balance.

Yancy Ribbens: Hi I’m Yancy Ribbens, I work for no one. I took a compilers class, had to use ML - favorite language is Rust recently - new for me, like type safety and reinvention - how to write memory safe code.

Yoshiaki Fukami: Hi Yoshiaki Fukami, working for Data Trading Alliance, an industrial consortium in Japan in Japan. I’m working for European Japanese reference architecture, identifiers are very important. I’m not a programmer, very difficult to choose.

Christopher Allen: Hi Christopher, I used to be with Blockstream, now with Blockstream Commons. I also do RWoT. I like highly constrained environments, most fun experience is implementing Forth in assembler - 12 words in assembler, rest is made by composing base words. I’d like to do that, but in principles of typed language, believe ML is one of them.

Michael Jones: Hi Mike Jones at Microsoft. Worked on a lot of different standards in identity space… OAuth, JWT, OpenID Connect - bringing some of that expertise to bear here. Want to make DIDs useful/simple while making things decentralized. I liked Bliss - DEC system DEC10, DEC 20, VAX - Bliss unofficially was an acronym for “Bill’s Language for Implementing Systems Software” - gave you full control over bits, bytes, pointers… but in a more typesafe and principled way. I write C# these days mostly because it’s easy.

Drummond Reed: Hi I’m Drummond Reed at Evernym, helped get this DID thing going. Not a programmer, except in ABNF, love ABNF. I have written a few things in Basic.

Sam Smith: Hi Sam Smith, worked in a lot of different things. Here on behalf of ConsenSys. Happy to be here. Also, worked in space for a while in IoT. Favorite programming language is Python - started using Python in version 1 in production.

Carsten Stöcker Hi Carsten from Spherity, physicist. I like DIDs because unknown actors will meet each other to establish trust using DIDs/VCs. I do a lot of C / C++, lots of simulation.

Oskar van Deventer: Hi Oskar from TNO, Dutch Research Institution. I’m technical coordinator for SSI arena focus on interoperability, integration, getting whole ecosystem running. I’m here to liaise with all of you. I like Java because I’m an organized guy.

Joe Andrieu: I’m Joe Andrieu, I’m here on behalf of Legendary Requirements. I do requirements engineering. I like lisp, like LPC (written in Amsterdam).

Michael Jones: I’d like to retract my favorite programming language, now xml2rfc. :)

Manu Sporny: laughing

Manu Sporny: Hi, I’m Manu, CEO of Digital Bazaar. One of the editors of the DID Spec, my favorite programming language is Javascript because it started messay and dirty , but turned into something that everyone uses.

Drummond Reed: Javascript = “the people’s language” = true

Michael Shea: Hi Michael Shea, independent, former programmer many years ago. C and C++ were my favorites - also leading task force for SSI and IoT for Sovrin Foundation. Seeing DIDs and IoT and some activity on mailing list - why I decided it was useful to join.

Oskar van Deventer: The European project eSSIF-Lab (essif-lab.eu) funds start-ups and SMEs to build useful SSI stuff: open-source components, generic SSI functionality and services, and sector-specific SSI applications. Email: oskar.vandeventer@tno.nl

Markus Sabadello: Hi Markus Sabadello, founder of Danube Tech. I’m here because everything I’m doing has to do w/ DIDs - foundational for Web. My favorite programming language is Java.

Drummond Reed: DIDs = “new foundation for the Web itself” = true

Eric Welton: Hi Eric Welton, I’m here because I like to write about what’s going on here. I like custom programming languages, fit for purpose.

Oliver Terbu: Hi Oliver Terbu, with ConsenSys - favorite programming language i C, C++, and now like TypeScript - like implementations for ReactNative, run on mobile backend. I’m here because DIDs are important, foundational for universal identity

Kaliya Young: Hi Kaliya, named IdentityWoman - mainly because only woman in the room (and here we are again). I also work w/ Wireline, interested in DIDs in existing world, less interested in how Web uses DIDs - PKI seems to be a focus, curiosity that I bring in terms of that - haven’t registered that much. I’ve been stewarding and leading in this community - thought there might be contentious things in this group, would like to moderate and help get us to other side.

Drummond Reed: Yeah Identitywoman!

Manu Sporny: This is important work.

Drummond Reed: +1 to Kaliya helping facilitate any embroglios

Kaliya Young: I don’t have a favorite programming language - if programming languages are about how you manifest into the world and create, as a facilitator - for me, Open Space Technology is something powerful that we’ve used in this community, that would be my favorite.

Ganesh Annan: Hi Ganesh Annan, from Digital Bazaar. I like how DIDs affect security and privacy considerations. Javascript is strongest, but really like Python - it’s followed me throughout my career. The versatility of Python is why I love it.

David Ezell: Hi David Ezell, represent Conexxus, we do standards in convenience retail. You have to have respect for C, Java, Javascript is getting better. Microsoft Macro Assembler was powerful. There is a property of decentralized technology that is important in the convenience store space.
… If you think of some of the specs we write, a central authority is “good enough”… problem is that’s a self selecting group, some thing centralized is fine, others don’t participate. We are interesetd in decentralized technologies in general. We have a project underway with National Association of Convenience Stores that starts w/ age verification. Why is it important to do this at W3C? Same reason that it was important that it was important to do XML at W3C.
… I’m here to offer that support.

Justin Richer: Hi Justin Richer, here from Bespoke - here on behalf of SecureKey - been doing a lot of work w/ them. Favorite programming language… did quite a bit in LambdaMoo - use Java the most, Python is great - list comprehensions are beautiful language constructions.
… I’m here because I want these technologies to succeed so I have more diverse tools to apply to projects. I have a lot of experience in standards space, like to bridge engineers w/ architects - I move between those spaces.

Juan Caballero: Hi Juan, work with Carsten at Spherity. I like C++, Python - don’t have strong opinions.

eugene: Hi Eugene, work with Jolocom - in Berlin. We work with Verifiable Credentials, excited to see where this space is going. As implementers, we want to be aware of discussions. I’m curious about some of the discussions we’re about to have today. I am a victim of Javascript/Typescript - enjoy Rust, Go - don’t know them enough to say I like them.

charles: Hi Charles from Jolocom, easier to get a feeling for things in person. I like TypeScript - Typescript is easy.

joachim: Hi Joachim, here from Jolocom, learning about different perspectives on topic of DID. Looking forward to learn more.

Daniel Burnett: Hi, Dan Burnett from ConsenSys - got involved before DIDs… walking by when Manu was presenting Verifiable Credentials, stopped and listened, and thought this is the right way to approach identity. Takes focus off of consolidation, definition, I believe that Verifiable Credentials and Decentralized Identifiers, not identity, are two technologies that can help solve these problems in a way that avoids consolidation.

Brent Zundel: We have next slide, as we discuss things, if there is something you want to talk about, add it to the slide.

2. Level Setting

See slides in the deck.

Daniel Burnett: I want to remind us all why we are here.
… The mission of the working group is to standardize the DID URI scheme, the DID data model, and (reading the slide)
… In scope (slide 12)

Daniel Burnett: the item about use cases is to talk about future uses for access management
… we will produce a note that is a refined use cases document
… the resolution spec is not in scope
… out of scope (slide 13)
… we will not define browser APIs, specific DID methods, or attempt to solve identity on the web.
… not an accident that none of our specs sayt we are solving identity.
… any questions
… deliverables (slide 14)
… some links (slide 15)
… summary of our w3c process
… (slide 16)
… working drafts don’t imply consensus
… it does not mean we agree.
… there is a point at which we believe it is technically complete, this is when we get to CR.
… then we need at least 2 implementations of each feature
… then we go to PR
… slide 17 (nice process picture)
… we also have a timeline
… our first public working draft was last year.
… we got a use cases and requirements note out
… we will talk about the rubric this meeting
… we backwards calculated the other dates
… (slide 18) has dates for each step in getting to CR and PR
… we need multiple CRs (I didn’t say that)
… we need our first CR my November 2020.
… we need a feature freeze in May 2020
… its easy to think we have time.
… we don’t
… After CR, there can’t be any substantive changes
… all this to say, this is why the chairs will be pushing to feature freeze.
… we don’t want to recharter to get our first spec out.
… for this meeting: the primary goal is to get agreement on the JSON/JSON-LD/Abstract data model question
… we cover background and necessary things day one.
… so that tomorrow we can get to a decision
… assuming we get that done, we can cover the other goals (slide 19)
… there are aspects of the metadata discussion that may be pertinent to our main goal
… any questions?

Joe Andrieu: metadata is today?

Daniel Burnett: this afternoon, so we have it in mind when we make the big decision
… for those of you who have slides, get them in
… is there anything in the agenda to talk about did resolution and what we’re doing?

Joe Andrieu: we should talk about the boundary between the two

Daniel Burnett: look at the agenda, if you don’t see a place where your comments will fit, let us know
… we’re trying to get knowledge without going into a rathole
… any otherr questions?
… a story I want to tell
… (standing) My technical background is in computer speech recognition.
… I had to decide whether to continue with that or to continue with standards.
… I jumped into WebRTC with both feet.
… it has spawned better work in W3C and IETF
… but, something very bad happened
… we started working on a standard. One company that didn’t participate started promulgating a competing standard.
… that did not result in what they wanted.
… it resulted in horrendous confusion
… companies looking to deploy, came in and saw the battle.
… investment dried up.
… conflict results in everybody losing
… it is important that we come together to write A standard
… that’s what matters (even if there are different formats)
… we will talk about extensibility and interoperability
… if you’re frustrated, talk more with those you disagree with
… don’t leave, that will damage the industry
… others have chimed in with similar stories
… any questions?

Eric Welton: I was asked to look at DIDs, because a company I worked for wanted to determine if they had cooled down enough to actually use

Christopher Allen: A little more history - co-author of SSL/TLS and led group that made TLS the international standard that it is today. We had these conflicts then - one of the big breakthroughs was - we found where we could have all of the important stuff in common, and then very few things we could go in radical different direction. The design allowed for more, that helped us break through impasse.
… We got 80% in common, how you get up to certain part of protocol, then had ciphersuites - you had to specify those, and as separate RFCs. If we tried to just pick a few, it would’ve failed. I think that’s a pattern in standards design - coming up with 20% agreement, then more until 80%.

Daniel Burnett: This is the standards process, this is normal. This is completely normal to disagree at beginning, standards process is writing down when you agree, then keep building on that stuff. Often end up w/ what Christopher said. I can provide my input on interop for standards (over a beer). Standards are useful for companies because it reduces the development time.

3. security

See slides in the deck.

Brent Zundel: Two weeks ago, Dr. Sam Smith provided a deep dive into security concerns wrt. spec. I did my best to summarize, might have oversimplified… summary is that each DID Method has a different solution for verification and control of a DID. Different protocols, infrastructure, this is the big concern. We need to keep this in mind while moving forward.
… We are designing an architecture that could have a lot of badness - what other concerns around architecture concerns should we have as we have in mind.

Michael Shea: When you say verification of control, what do you mean?

Brent Zundel: Well, resolution we need to make that’s secure, code on computer is secure, DID Document stored on ledger, what are ledger guarantees? Is it peer or key did, is it self-certifying? etc.

Manu Sporny: implementation complexity is also something
… we want a secure system, so we make sure we do things in a limited way
… so they can be implemented in the right way.
… this limits implementation at the edges.
… we don’t know where this tech is going. we are going to enable some flexibility.
… this may allow implementors to shoot themselves in the foot

Christopher Allen: I’d like to speak for innovation in cryptography and cryptographic systems - especially over last decade and last 2-3 years, we’re going way beyond crypto of today. Most of this stuff is coming from crypto communities… cryptographic circuits, multisignatures, zero knowledge proofs, scriptless scripts - cambrian explosion right now.
… JOSE was a disaster when it came out, everything is a disaster when it comes out, but it’s roots are in 1980s single signature technologies - we’re able to go beyond that. I’m not saying don’t support more proven types of approaches, but don’t lock out emerging technologies, because we could lose it all if folks go w/ new emerging technologies.

Eric Welton: Is the goal for security to try to solve a meta process vs. identify characteristics concerns and address them as rubrics.

Joe Andrieu: It’s going to be vital for us to distinguish in conversations and spec, proof of control over DID Document and authenticating as the DID. People conflate those two, different use cases, analyze them differently. DID Control is method specific, two different surface areas - let’s talk about them as different things.

Kenneth Ebert: Even though ZKPs are strong in Sovrin ecosystem, we’re upgrading those now - if we lock ourselves in, we will lock out the future and not be able to migrate forward. We need some sort of rubric to test minimum security levels. We do want to shut out insecure systems.

Samuel Smith: I’ve been thinking about this problem for a while, one of the things that might be helpful is to step back and think about how we layer security - cryptographic agility, how we address infrastructure differences, if we layer this right, we can get best of both worlds. If we layer it wrong, we’ll bifurcate the trust map and make the rest of history a never ending retreat/fallback positions and security patches.
… My biggest concern is that we’re failing badly from a security design perspective - we’ve maximized ability for people to exploit.

Ivan Herman: More a question coming from a non-expert… I haven’t seen anything in document for biometrics / FaceID - is this ok, do we want to have bridges for that? What do we do there.

Drummond Reed: I wanted to reinforce what sam said, first on extensibility - no way people in room will know right security practices 5 years from now… we need to allow for extensibility and innovation - many of problems on how to deploy securely is something we want to consider, but these are not in scope. Let’s make sure we get layering right, but let’s not inhibit innovation.
… Let’s not block innovation.

Michael Jones: I wanted to second Chris’ point about cryptographic agility and innovation, we don’t know what algorithms are needed for what use cases in future. We don’t know what’ll become compromised next week. Any long term standard in security must ensure innovation in 20% for systems that update at their own pace.

Joe Andrieu: Wanted to respond to Ivan - in part on use cases work - there is a huge amount of concern around privacy and biometrics - there is conflation around DID Method and biometrics - no one has proposed biometrics yet, but design allows for it, but want to move biometrics to the edge, like a phone, don’t put them in DID Document. The ultimate mechanism is cryptographic, keys secured biometrically.

Ivan Herman: We may want to put that in the document.

Markus Sabadello: The way the spec and DID Method specs, DIDs inherit underlying DID methods - facebook method only as secure as facebook. Is that a feature? Or do we want stronger security properties?

Oliver Terbu: We have to limit the decentralized extensibility model to uphold certain amount of security properties… isn’t W3C DID Method registry already a registry for such features?
… Imagine you extend DID Method in a way that changes security mechanism for basic DID Method - that’s a problem that needs to be solved, we should have an IANA registry, limit scope of extensibility to certain scope, like authoritative keys.

Manu Sporny: We could extend DID Method Registry, we’ll talk about that. We do want to limit DID Methods from overriding how security primitives in DID Core work.

Brent Zundel: What should we do about these issues? We could require DID Method to follow common practice, how do we layer security, security considerations, bad practices, rubric?

Michael Jones: I did something dangerous on flight here and read every word of DID spec, one of the things I read was that there were places where spec imposes requirements on DID Methods. Security considerations, privacy considerations. I agree with Manu’s suggestion that methods shouldn’t change core functionality - impose requirements on DID Methods, even though we’re not doing a protocol spec, data model spec.

Kenneth Ebert: We’ll need some sort of rubric to evaluate.
… The number of DID Methods is growing, we’re over 40 now, we will need a rubric.

Joe Andrieu: I want to endorse the idea of a rubric, we’ve been working on one about decentralization - doesn’t address security, doesn’t support privacy.
… We need to clarify security related to key management, and security assuming keys are well managed. Best we can do w/ key management to point to external references… if keys are compromised, everything is off. We should separate those two things.

Eric Welton: About layer/layering - what does that mean?

Manu Sporny: Not to argue … Concerned with how much we are asking humans to do (bad for security). DID core spec has normative language around DID methods. Humans have to read and understand this in approving DID methods, which may ultimately fail. These rubric docs will be very complex human-readable docs. Headed towards 50-90 items that an expert has to check for each and every DID method.
… some have argued decentralized extensibility is bad. My argument somewhat agrees with this, unfortunately. We need to consider this.

Yancy Ribbens: The best way to harden a system is to reduce the attack surface - that means we should focus on bare minimum essentials are - segues into thing slike matrix parameters, what are use cases, we should minimize feature sets to helps us be as secure as possible.

Samuel Smith: First bullet, make DID Methods follow same thing to establish control authority - maybe we can do a trust spanning layer hour glass approach - standard set of config data, looks like events - we say it’s too late to put the genie back in the bottle - that’s bad for security, but look at ecosystem, if we design DID Method the right way, all other DID Methods will die and we’ll be left w/ 1-2 DID Methods, layered security model - roots of trust, ability for that config to change the establishment mechanism, we get all we need. If you have too much extensibility, you get OpenSSL OpenVPN - too much agility to do something wrong.
… If we built ideal DID Method, and that wins in market, that’s great.

Markus Sabadello: Building ideal DID Method, with ideal properties - what if other DID methods that were not as good, keep going, like did:web - the point of the decentralization rubric is not to come up with the one best thing. Maybe security rubric could have the same. KERI-based ones are more secure than DNS based ones?

Brent Zundel: First one doesn’t seem to be possible… which of these others? Where do we want to go - add things to security considerations.
… Do we want to do a rubric to start? Expand test suite to look for specific security considerations? DID Method can algorithmically done? What does the group want to do?

Christopher Allen: I am concerned that there has to be a common practice - I have a demo of multisig control authority that can’t be implemented - it’s self-sovereign multisig - I have a Tor based connection to a node I control, 3 keys, can do multisig, but not with what we have right now. I don’t think there’ll be a common practice.

Manu Sporny: we need to write much of this down into security section, until it gets large enough to deserve its own doc. +1 to joe’s comment about a rubric. Don’t like security rubric, because it needs to be firm guidance.

Joe Andrieu: I think we need to do a rubric, it’s going to take a lot longer than people realize, but we can’t provide direct guidance.

Ganesh Annan: Establishing common practice, sounds like protocol issue - what can we state about this stuff?

Manu Sporny: we need to give guidance, which can’t happen in a rubric

Brent Zundel: We can normatively require DID Methods to implement themselves in a certain way.

4. DIDs and IoT

See slides in the deck.

Samuel Smith: IoT Characteristics - large number of devices, 80 billion by 2025 - by and large, IPv6 - probably see Internet switch over next 5 years… 5G is almost 100% IPv6… rest of world using IPv6.
… This is a driving function, there will be way more IoT devices, need identifiers, than everything that we do combined, these devices are limited resources - example, IETF CoAP - UDP alternative, DTLS/CBOR solution - two major groups, industrial Internet of Things - commercial vs. home.
… Differences between two are significant - many of these devices are industrial IoT. This building we’re in HVAC, security systems, IoT things - what tends to happen is integration is happening in the cloud - all device families are siloed, HVAC vendor, window treatments, have non interop devices - only way they can talk together, operationally integrate w/ the cloud - that’s a challenging problem, they can’t talk to each other in same building.
… Data integration, not just talking to each other, - future is, there is not enough cloud compute capability to manage those sorts of things, zettabytes - future, has to be done on the edge. Strong driver for DIDs to have ability to authenticate in edge, do operational integration in edge.
… Two types of devices - direct IP enabled devices, home automation - indirect IP enabled - some non IP stack, IP gateway device, bluetooth, zigbee, non-IP stack devices might talk to gateway - tends to happen more in commercial IoT makes it cost effective to have a gateway.
… In general, authenticated control is more important than confidentiality.
… CoAP based system, gateway - diagram explanation
… The biggest issue for IoT is security - IoT devices are in public building, someone can pull device, mess with it, may not know.
… That is an overarching concern, problem w/ IoT is most devices have default credentials. 90% of installers don’t change default passwords.

Christopher Allen: They are no longer going to allow that.

Samuel Smith: Some devices only have LAN access, some have unencrypted data, anything we do as identifier standard that requires WAN access, no LAN version, just won’t work.
… Edge vs. Cloud integration - future will be edge, devices are not self-sovereign in any way. Edge integration, that would have to change.
… IoT provisioning - typical provisioning method, some sort of on device label - limited physical security.
… number sticker, scratch off ID, barcodes, QRCodes - anything more complex is going to fail.
… puts an upper limit to fully support IoT, how complex can provisioning be? Bootstrapping identifier, not going to be adoptable if it’s heavyweight.
… If you can do a self-contained boostrap, you can simplify the system. Some devices are using contextual information, looking at nearby devices, won’t authenticate them - different location, most cases, IoT devices have low value, no need for persistent identifier - self-certifying identifiers, you don’t need anything - if something has been hacked, throw it away, reprovision.
… Rarely do these things communicate pairwise - get out of lan onto gateway.
… Future is non-siloed edge integration, sensors with authorized telemetry, actuators… there is already an alternative standards tack IETF/TCG - Device ID - Implicit Identifier. Implicit identity, self certifying id created on first power up. This one is private, manufacturer doesn’t know private key, on power up, generates key on boot up. Any tampering creates new DID.
… This is a CBOR/JSON CWT spec.
… IoT Interop - oBIX, XML based legacy 1990s…
… numerous walled garden standards, numerous consortia - in Europe, IoT EPI - big tent approach, mostly architecture, not implementation,
… Project Haystacks getting the most adoption, uses tag model - key-value pair w/ registered set of tags, simple model, easy portability - broad adoption - winning over industry consortia
… Interesting thing - Haystacks achieved broad industry adoption via tagged semantic model, brix project, haystacks tag ontology as overly to enable some RDF models to sit on top of haystacks. Doesn’t encumber underlying encodings while allowing any RDF standard encoding to apply to this model.
… That’s the end…
… Are we going to integrate w/ IoT? Constrained encodings, CBOR…

Manu Sporny: great info, thanks. we are clearly missing this big sector.
… how do we liaise with them. Have we missed the boat?
… sounds compatible with did:key.

Samuel Smith: yes.

Manu Sporny: we need to reach out and share that.
… w3c has web of things working group that is connected here.

Samuel Smith: haystack tag ontology group is using W3C stuff.
… they do an overlay using W3C standards

Manu Sporny: WoT uses JSON-LD

Manu Sporny: need to see what they needed in WoT to make everything work

Samuel Smith: defined dictionary with meta-semantic model
… for large factory automation projects, worth overhead to map to semantic model for benefit of data analytics
… in most cases simple tags are enough.
… for big buildings with thousands of devices the semantic overlay is helpful

David Ezell: Second the shout out to Web of Things - deeply embedded in company projects, security meeting is 8am ET - rough hour, think this group should engage with them. This aspect is important part of DIDs. Was present on PSIG review of PR for Web of Things - security folks had two issues, one was the presence of “id:” in thing description, could be subject to replay attack, or recognition of endpoint if you didn’t know it was… Security section in document, security section is non-normative, was a big issue in their work.

Joe Andrieu: Has anyone looked at Filament? Jeremy Miller, XMPP?

Samuel Smith: Looked at filament, lots of industry specific protocols, Nest guys (filament) – Jeremy Miller, Telehash used for IoT stuff. Hundreds of them

Manu Sporny: Fun fact: earliest DID method we know of was implemented using Telehash :)

Christopher Allen: There is a great connection in crypto security industry around problems w/ security - verification w/ hardware crypto, as an example, box we did w/ Blockchain commons - paper display on one side, you can route to my mac via Onion, key ops w/ QRCodes - also do this w/ VPS, keys are completely split - device can’t sign anything by itself. The thing it talks to contributes signature - VC is only valid once it reaches threshold of attestment. Multisignature - VC proof would say you have to have at least two of 10 instruments for it to be valid… and approval of the cloud device.
… These are the things we’re doing in cryptocurrency space, I want to see this stuff - there is a mesh there w/ IoT, but we’re doing more sophisticated crypto.

5. Encodings

See slides in the deck.

Markus Sabadello: Not going to go into the hard details about how interop and everything works.
… we want to look at some of the formats and syntaxes that have been discussed
… found nine : JON-LD, JSON, IPLD, CBOR, XML, PDF, ASN.1, YAML, XDI
… please add to slide if you know of others (but don’t delete)
… Let’s start with JSON-LD
… Primary format in the spec. Been there since the beginning
… based on semantic web principles and RDF graph model
… linked data / RDF has a background connected to decentralization on the web.
… Ivan’s paper: the web is about linking. linked data is trying to do the same thing for data.
… Some may remember FOAF: where you can point to other identifiers who are my friends
… for these JSON-LD is great. permissionless extensibility. compatibility with a bunch of things
… Also a lot of interest in JSON (pure JSON)
… ubiquitous support, familiar to developers. no external network dependencies, compatibility with a bunch of things (JOSE, OIDC, DIDComm)
… Another is IPLD
… content-addressable, distributed storage, location- & protocol- independent
… censorship resistant
… CBOR has also been mentioned. Also used in IPLD
… very compact. great for IoT. easy to map to JSON
… might be possible to do JSON-LD in CBOR
… but also maybe pure JSON in CBOR
… So what do we mean by data model, syntax, serialization, etc.
… XML: obviously the best for everything
… good for data-types, namespaces, lots of tooling
… PDF has been proposed. Express a DID Document as PDF.
… not so much as human readable PDF, but rather embedding a DID Document in a machine readable form inside a DID Document
… These are some of the formats, some of the discussions we have had in the community on this topic
… We can’t have this discussion in isolation. We can’t just compare these two directly.
… There are dependencies on the intentions for DIDs
… What’s the purpose of the DID Document?
… Did document describes the subject -> JSON-LD preference
… if DID Document contains meta-data for interacting with the subject -> JSON Preference
… Similarly, do we think DIDs are part of the web?
… are DID Documents resources on the web -> JSON-LD Preference
… if DID Documents are more like DNS records -> JSON preference
… -> likely affinity between world view and technical approach
… Some DID Methods don’t care the format of the DID Document.
… But for example, did:sov doesn’t have native support for any of the proposals. they store it on its own format.
… the ethereum smart contract based DIDs tend to treat the Document as virtual, serializing as necessary
… did:key is currently JSON-LD, but it is so simple and constrained, you may not actually be using any of the features of JSON-LD and might be better suited for “pure JSON”
… other dependencies include support for public key formats
… We just added JWK support, but do we really want a JWK public key inside an XML or CBOR DID Document?
… How would we do that? It would be more natural to do everything in the chosen format
… Fragments in DID URLs: dereferencing fragments is not defined by the DID core spec, but rather on the mime-type
… so if we have multiple encodings, that might change the semantics fragment identifiers
… Let’s discuss: interop, extensibility, resolver behavior

Manu Sporny: two things
… One. I don’t know if people knew to the group. VC spec and DID core spec, the goal was to use a subset between all these formats.
… so, we strove to use the minimal subset you can represent in JSON, CBOR, and JSON-LD
… so, even those the VC spec says it’s JSON-LD, it is actually a very limited subset
… So, we don’t necessarily have network dependencies (because we are using a subset of JSON-LD)
… specifically, one should not go out to the network in run-time
… for things you don’t understand
… On the other hand, in some cases, you go out to the network regardless of format

Daniel Burnett: still a good portion of the world that uses XML
… it’s not crazy to assume that maybe there will be an XML representation
… Second, when we started, the DID Document was a physical representation, but it is not required that it ever be stored anywhere.
… this is an explicit requirement: the document is not the thing, it’s the information in the document that matters

Joe Andrieu: Markus, you had suggested that if the metal model for a DID Document is how to interact with the subject, you might go to JSON. I’m flipped, I don’t see that at all.
… real quick. Markus suggested the mental model for a DID doc is how to interact with the subject, the format is JSON. I’m not seeing that
… Don’t think I need to spend more time on that, but I don’t see the affinity.

Tobias Looker: If we make all of these encodings first class options, then we have content negotiation as a huge upfront requirement for everyone using the tech
… but we need to know what level we are supporting these alternatives
… What is a DID Document? A lot of time… is it a rendering of events into the current state? Or is it the actual thing the decentralized system actually represents

Oliver Terbu: re: fragment semantics: we are writing specifications for the did data model and did -resolution and it doesn’t seem to be a problem

Samuel Smith: I think there is still confusion about what the purpose of a DID Document is.
… the first thing you need to do is establish control authority?
… the way methods are being written its not clear where we are on this question

Justin Richer: +1 to sam’s point on information models

Samuel Smith: I’m not talking about the data model, but the information model
… if you think about what happens with a URL: before you go to a given server, you have to resolve the authority
… Are we going to standardize that establishment of control authority

Christopher Allen: some people already touched on my issues

Kenneth Ebert: concur with Markus: there’s a difference between our internal representations and what are present to the outside.
… we expect to be able to publish multiple serializations for interoperability

Christopher Allen: One of the problems I’m seeing is that we are not talking about who the audience is for the DID document
… If I’m a consumer of the app, I really don’t care how rotation happens. I’ll defer that to a resolver.
… however if I am writing a resolver, then I do care about those things
… I’m a little worried we aren’t thinking about these differences

Justin Richer: +1 to that
… we need to be honest about what the DID Document structure is
… we need to be very careful about what is expressed AND expressible in a DID Document
… that gets to the core of what I see in the debate
… What I’m seeing is “use JSON-LD” but turn off all the stuff that makes JSON-LD special
… so can we count on that extensibility? or Should we assume it is turned off?
… Or on the JSON side, can we be sure we only have strings, numbers, etc.?
… Given Markus’s big list is great. (NO to ASN.1 but glad its considered)
… we need to get to the lowest common denominator
… if this working group wants to be able to depend on LD structures to understand that a field is a particular type, etc., a date
… instead we have JSON-LD docs that aren’t really JSON-LD
… and vice-versa
… [I mean JSON docs that aren’t really JSON]

6. Different Encodings: Model Incompatibilities

See slides in the deck.

Manu Sporny: Things to be aware of as we go into the discussion.
… Different encodings: Model incompatibilities
… Four categories: primitives, structure, canonical form, extensibility
… [nice concise definitions of those four]
… A bunch of primitives that are or are not supported in different models
… Integers as keys (including negatives), BigNums, Byte Strings, ordered sets and unordered sets
… Does order matter? Where? When?
… tagged values and tagged types. “This is an IP address”
… number representations in different platforms matter.
… JSON states numbers can be infinite, but reality is different. Typically 32 or 64 bit, depending on platforms
… In short: this is not a simple choice
… Data Model structures: three kinds
… 1 Flat Structure (flat name-value pairs)
… 2 Tree structure (most formats allow this).
… but the question is does the structure imply anything semantically. Typically yes, but what?
… Do certain names mean something? “id” in JSON-LD does. In JSON it doesn’t.
… Can you have arbitrary references to other entries in the document?
… Because of that referencebility wrt public keys, we are almost certainly using a graph structure not a tree structure
… 3. Graph structure?

Jonathan Holt: technically, CBOR does specify a ‘canonical form’ in the RFC see: https://tools.ietf.org/html/rfc7049#section-3.9

Manu Sporny: Canonical Forms
… CBOR does not have a canonical form
… One has to be defined by the protocol. CBOR doesn’t haven’t it implicitly. Rather the spec gives guidance on how to do it.
… JSON does not have a canonical form, but there are schemes for doing it (JCS), but has corner cases.
… JSON-LD does have a canonical form
… that form is not a standard yet, but there is work happening in that direction.
… if we care about digital signatures, then we care about canonical forms
… Extensibility:
… If we use @context from JSON-LD and the JSON encoding doesn’t, then we have two completely different models for extensibility
… If JSON-Only uses registry, do JSON-LD implementations have to pay attention to it?
… How do you know if your implementation is up to date with the current registry?
… This comes down to: do we want a canonical form, how do we sign it without introducing security problems
… buckets!
… That means put extensions in a particular property, but then there is a question about what others should do if they find a bucket they don’t understand.
… these are not the only things
… what else are there?

Michael Jones: Two responses
… in passing, Manu, you promulgated the assumption that canonicalization is necessary to sign. It is not.
… Canonicalization is one way to do it. But JWT signs without canonicalization.
… so we don’t need to deal with that hairball

Manu Sporny: We have a mismatch of definitions… I agree with Mike that you can do it.

Michael Jones: Different point: CBOR v JSON
… Occam’s razor suggests that we make the CBOR one exactly the JSON representation applying a standard translation to CBOR and not doing CBOR specific things

Jonathan Holt: just to plug IPLD…. pass

Justin Richer: -1 to version fields

Oliver Terbu: staying up to date with JSON & registries is a hard problem to solve. but we could maybe deal with that with a version field

Christopher Allen: first, to respond to you have to have the entire JSON thing along with it.
… that means that signature chains mean an explosion of sizes. so JSON not so great for multi-sig
… I’m one of those people who likes JSON-LD for a different reason.
… A lot of us came to JSON-LD because of the open world model and graphs, into JSON-LD from RDF
… I came into JSON-LD because I can do a merkle-tree of the quads. I can do that with JSON-LD, but not with JSON.
… I have a bunch of statements in JSON-LD, with each independently provable.
… It’s the simplest form of data minimization you can do. In contrast to issuing separate claims for every distinct assertion.
… You just can’t do that in some of these other stacks.
… We could separate from the JSON-LD thing from the canonicalization.
… Just give me a merkle-tree. and I’ll verify it

Samuel Smith: There are lots of standards that use much simpler data models and they work practically, and well
… there is a sense that if we don’t have the ideal level of extensibility and all of these features, then we have the impression that will be a problem.
… the real world is less about the ideal and more about practical adoption
… sometimes that is more important to us as a standards organization
… I spent ten years pushing superior tech that failed in the marketplace
… concern is that we tend to err on the side of being ideologues instead of what will work in the marketplace
… we should temper our conversations with a sense of adoptability

Daniel Burnett: everyone gets to say everything without censorship
… for now

Markus Sabadello: I liked Oliver’s comments about registries and versions
… Perhaps there is some way that a registry and JSON_LD context could be kept in sync

Drummond Reed: I want to reinforce something Sam said.
… I posted the first issue that we should look at an abstract data model
… all the discussion has made me even more passionate than ever
… I define that as the core data model. This is what we absolutely have to figure out and agree on.
… pure encoding is not the clear differentiator.
… They are all actually graph models with different complexity
… What we are solving is so low level… if we solve that ONE problem well, DIDs will be enormously successful, with NO extensibility at all
… this is not to say extensibility isn’t good, but that we must not fumble the ball

Daniel Burnett: lunch is coming up.
… I know we haven’t had enough time for discussion. We will have more time as we go.
… Please keep comments short to keep the conversation flowing.

7. Abstract Data Modeling Options

See slides in the deck.

Daniel Burnett: So far, we’ve just been talking about potential incompatibilities
… So I’m going to talk abstractly about abstract data models
… What are we modeling?
… Data processing (processing of a DID Doc)
… Data Storage
… Data transmission
… The processing we are talking about is various computer languages. We HAVE to be agnostic there.
… For storage, we’ll likely store them in databases, but that’s not really what we are standardizing here
… Schema definitions my help.
… For transmission, note we don’t have to use the same format as we do for storage
… Suggestion is that the transmission format is what we are modeling here
… Other than PDF, most of us are talking about transmission.
… This matters because it affects how you do modeling
… Why do people use JSON?
… It basically was an alternative to XML for transmission
… I’ve done tones of XML. JSON is effectively a wire format for messages transmission and exchange.
… By that, I mean a specific serialization
… Alternatives to JSON for serialization of Data: CSV, XML, YAML, CBOR
… Argument: we should not be picking one, we should be using an abstract data model that works with any of these serialization
… What level are we defining?
… Spec was designed to be an abstract (exchange data model)
… could definite at different levels
… A Conceptual data model define semantic roles and relationship without getting into syntax
… typically uses a graphical representation that simplify an overview
… Examples: object role model (ORM, very high level)
… or Entity Relationship Model(express, UML, IDEFIX)
… A structural level presents roles and relationship as fields (sometimes with syntactic requirements)
… if we choose a modeling language that also allows us to model ties to procedures is that implementers could then take that model and extend it, using that modeling language to provide the computation support they need.
… All of that is out of scope, but if we use such a language, it might help downstream adoption
… Bunch of examples of favorite structural modeling languages
… Are we modeling a transmission model?
… and are we modeling a conceptual or structural model?
… suggestion we should probably go to a structural model, with a format that has a graphical representation
… it’s just so nice for explaining to people what we are doing.
… Example structural formats: EXPRESS, Protobuf, UML, IDEF1X

Joe Andrieu: [see slides for details]

Daniel Burnett: those are the examples. we don’t have to pick from just one of these.
… this was to help us understand what our choices are as we consider abstract data models
… This is a UML diagram that was complete and correct.
… Some of the terms have changed, but it was accurate at the time.k
… This avoids the bias of any particular syntax.
… But we couldn’t get anyone to write a specific syntax EXCEPT JSON-LD, so we got rid of the UML and moved forward with JSON-LD.
… We’d love to have this for DIDs, we just need people to step up and produce them.

David Ezell: I’m wondering why JSON Schema didn’t make the list.
… it is the underlying spec for [something] . I’m a UML fan, but the value comes out in a tooling
… the graphs turn into real code.

Ivan Herman: JSON Schema is a moving target. They keep coming up with new versions. Stability is a problem.
… we have had discussions with the JSON Schema people. They keep saying “sure a real standard would be great”.
… We have editors who have to create documents. Which are the ones that have good tools for editors?

Justin Richer: big +1 to transmission and structural format coverage. There are assumptions that get glazed over
… if we really are an abstract data format, then our data format need to actual exist and be serializable
… what we have been doing a bad job at is realizing what those costs and weights are for other people
… We often look at these as how easy it is for us in the group, without awareness of what it means for others.

Drummond Reed: as one who is passionate about abstract data models, I will volunteer, if we do UML

Manu Sporny: Agree that we are doing a transmission and structural format
… I had thought we were ALREADY doing a data model spec. I don’t think there is much debate to be had at this level.
… We can argue details, but there doesn’t seem to be anything controversial here.

Daniel Burnett: right, but there are lots of people who may not have realized that we are making an abstract data model and what that means to our collaboration

David Ezell: I’d like to reference the XMLInfoset spec: https://www.w3.org/TR/xml-infoset/. It’s purpose was to decouple XML syntax from the information content. Probably worth a look.

Manu Sporny: the diagrams in the VC spec were removed because of feedback from implementers

Daniel Burnett: yes. I’m not saying we should have ONLY visual representations
… we are chartered to define a data model AND one or more specific data realizations
… LUNCH!

Brent Zundel: Zoom Link for audio: https://zoom.us/j/5593214233

Brent Zundel: Who’s going to dinner?
… 21 people.

8. DID Doc Extensibility via Registries

See slides in the deck.

Michael Jones: What to registries accomplish?
… They prevent name collisions.
… And provide authoritative links to where to find definitions.
… Identifiers can use names with the same meaning.

Juan Caballero: https://tools.ietf.org/html/rfc7518

Michael Jones: Samples are IANA web token claim registry.

Juan Caballero: (JWA spec mentioned in ref to prev slide)

Michael Jones: See https://www.iana.org/assignments/jwt/jwt.xhtml
… (Explain sample)
… Claims for specific use cases are included.
… Specifications are required to add to IANA JSON Web Token Claims pending expert review.
… Second example: https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
… How to add to a registry?
… This is a decentralized method of publishing definitions.
… The DID spec prohibits redefinition of terms.
… Registries can help us avoid conflicts.

Justin Richer: An important note when looking at the suite of JOSE fields. It creates a source for enumeration of fields.
… I think this is strongly needed so that implementors can follow the directions in the documentation.
… The registry tells the implementor what they have to do.
… When I see that field, I know what library to point at it.

Justin Richer: to clarify, I believe we really need this for DID methods

Kenneth Ebert: self-issued: Claiming there is no registry does a disservice to implementors.

Justin Richer: From a normative standpoint.
… I think that is a mistake.
… I filed an issue on that topic.

Justin Richer: I want to point out to everyone that this mapping is explicitly in the WG charter

Justin Richer: Especially with identifiers that are not human readable.
… A more normal practice is to use human readable names.

Manu Sporny: Depending on the definition of decentralized, registries have high process when there is disagreement.
… Disagreement can be legit or political.

Kenneth Ebert: self-issued: Fair enough. Usually there are directions to the reviewers to guide their actions.

Markus Sabadello: Mike, do you think the registry approach will work with high volumes of additions?
… Right now these are handled by JSON-LD definitions.
… With 1000s being added I wonder if a registry can handle it.
… Would it make sense for service types?

Daniel Burnett: So there is a bar to entry for adding to a registry - not necessarily a bad thing

Kenneth Ebert: self-issued: I would hope that service types would be registered. If not, how do implementors find out what the interoperability is supposed to be?

Markus Sabadello: The registry says these are the service definitions that digital-bazaar created, or ChristopherA created.

Eric Welton: registries require explicit, intentional interoperability - but an open-world model will allow opportunistic, emergent interoperability

Drummond Reed: I put the original text in. Sorry
… I never expected we would have over 40 methods.
… It has grown beyond expectations.
… Point 2 Registries are a method, but not the only method.
… The core features are in the spec. The extensions are not.
… Both methods can work together.

Samuel Smith: We have an informal method name. The rest can be defined within the method spec.
… The model can name space to avoid collisions.
… Namespaces are good; we should have more of them!

Kenneth Ebert: self-issued: RFC7515

Samuel Smith: Search for collision.
… JWS spec discussion of names. Public names are registered.
… Collisions resistant names use some natural prefixes to prevent collision.
… Using my domain name as the prefix helps me define my own “namespace”
… There are other collision resistant names that are longer and not registered.

Jonathan Holt: as an aside, OIDs are a valid URIs

Samuel Smith: You lose the definition if it is not registered.

Christopher Allen: An early proposal involved a whole block chain to register all the names.
… It was too complicated.
… A five level staging system involved documentation, implementation, live-system, etc.
… It was censorship-resistant.

Justin Richer: +1 to the levels and measures, this is what the normative teeth would apply to

Christopher Allen: I suspect that only a few will make it all the way through.
… It’s probably out of scope for this group to set up all and run a registry long-term.

Joe Andrieu: With an eye to compromise, I think there is a difference between method and property name spaces.
… They should be treated differently.

Justin Richer: +1 to them being separable, though I’d add they might have the same solution

Christopher Allen: provisional, conformance/test available, reference implementation available, live test available, poc available, in production, deprecated

9. DID Doc Extensibility using JSON-LD

See slides in the deck.

Manu Sporny: Why might we want to do this?
… Add method-specific properties.
… Add new service types.
… Add cryptographic methods.
… Or merge data with Verifiable Credentials.
… To extend a DID Doc with JSON-LD you define a vocabulary, create a context, and append it to an @context property.
… A simple single feature would take about an hour.
… Using the new context is very simple.
… There is no formal mechanism, unlike a registry.
… For JSON-only developers, you need to update your schema and validation.
… Security may require some restrictions to JSON-LD extensions.
… Decentralized extensibility can reduce peer reviews.
… Sometimes JSON-LD is too complex for a use case.
… Benefits include reduced roadblocks from the workgroup or registry.
… Property conflicts are eliminated.
… This method of extensibility is compatible with VC data model.
… That’s it.

Phil Archer: I’m with GS1.
… A benefit is that it prevents the reinvention of the wheel.
… We have a bunch of service types.
… I’d like the existent context we have to be useful to others.

Jonathan Holt: I am concerned about cross-domain ontologies.
… Having a single domain be the authoritative source for the context is a potential security issue.

Christopher Allen: Both DID docs and claims are about the subject.
… We had our DID doc be a VC that was self-signed.
… A second signature was base on a satoshi’s signature.
… Extensibility could be provided by VCs.

Joe Andrieu: The method name space should be considered separately from the property name space.
… We will have differences of meaning regarding a property with the same name.
… I want less in the did document.
… I don’t want all the service endpoints in the did doc.
… If we can reduce the amount of data in the did doc, fewer extensions will be needed.

Markus Sabadello: Earlier we wanted to avoid registering did methods.
… It brings us back to the definition of the purpose of the did doc.
… Is it a minimal document for the did and small service endpoint
… Or is it a represent of “me” more completely?
… What happens when the registry potentially gets compromised?
… Compromising the semantic meaning of properties is also a risk.

Eric Welton: What can the did doc represent?
… We mostly agree on the core fields, but what about the fields beyond that?
… We can give guidance on how extensibility works.
… A set of VCs might be a better way to extend the data in the did doc?
… This group has very few women or Asians in it and will reflect our biases.
… I am more in favor of the open world model.

Manu Sporny: Responding to “http” for contexts. There are other methods.
… re: “I’m concerned about centralization of semantic meaning.” Some thought (20 years) has gone into this.

Juan Caballero: https://wiki.dbpedia.org/

Manu Sporny: Schema.org is an example.
… You can disagree and put up your own definition.

Jonathan Holt: I am struck by the one source of truth and reliance on http protocols.
… A centralized model vs. a decentralized model.

Drummond Reed: I love the “turtles all the way down” analogy - we always need to keep that in mind with DID documents

Brent Zundel: Can we discuss the remaining queue after break?

10. continued Extensibility discussion

See slides in the deck.

Ivan Herman: look at dbpedia as the machine readable version of all the media wikipedia has put together

Ivan Herman: if I’m on the linked data world, my data can be combined and put into dbpedia
… there are a large number of these databases
… public domain etc
… you can think of it in smaller terms
… some vc credentials and all the way of combining data in one credential is what it’s all about
… if we have that, and this is a use case for us, then json-ld can be used for that
… we need to decide on the use-cases

Michael Jones: does combine mean both from my databases into another

Ivan Herman: imagine this is one big database and you have a query with all the details
… just saying that this is a possible use case

Samuel Smith: my suggestion is that we two types of docs that we discuss extensibility for
… this is from the presentation I gave to the wg a week ago
… there are two activities that happened when accessing a did
… there are two roots of trust
… cryptographic and infrastructure
… infrastucture is a blockchain
… and you’re dependant on the distributed concensus
… cryptographic is one that’s signed
… it’s a self-cert
… some people provide proof in a DID doc
… that type of establishment doesn’t need any extensive amount of extensibility
… once you’ve established it
… they are no longer a security vector
… common authorizations can have a line drawn
… can draw at establish auth
… or above service authorization
… arguments for open world or infinite become valid in that case
… I think that’s the problem is that we need to make separation of concerns

Michael Jones: people seem concerned about having a fixed set of people deciding whats part of the record
… this wg is part of such a group
… we seem to be ok doing that

Manu Sporny: I think that before we had a discussion about a layer that’s pre-did document
… I think the part you’re concerned about is what happens before the did doc is crated
… I think we should seperate them
… bu I don’t know if this group should separate them
… I want to point out that its under the extensibility discussion

Samuel Smith: some extensibility could go into that document
… then you auth an encryption
… if you look at in terms of iot…

Manu Sporny: there are a lot of other uses cases that come up
… veres one stores did docs
… the ledger is built around the mechanism

Yancy Ribbens: mechanism

Manu Sporny: we merge data sources on a regular basis
… there are many times when json-ld is useful
… we also have use cases where some did docs refer to other did docs
… in some cases they are associated
… there are use cases that are not yours that are feeding into the desire to have more complex use cases

Markus Sabadello: json-ld context is a type of registry
… that’s not so different then a registry
… it’s just anyone can run there own registry

Daniel Burnett: from rfc 3968
… basically there is resolution and de-referencing
… slide 93
… in the process of doing resolution we realized there are these things you need to do
… but there’s no requirement that they need to be stored that way
… the did doc was just an idea about this stuff
… and gradually stuff started to be added
… originally this was just a way to give information that was asked for
… we may have chained our minds, but this was the original way it worked
… that’s why some of us say the format doesn’t matter
… in order to understand the de-ref you need to understand a resource

Joe Andrieu: I like the separation of authority

Yancy Ribbens: .. and what does that mean

Sam Smith: I think it’s a problem with how identifiers are used

Joe Andrieu: I know this will make you said but to answer the question I think the link is an anti-pattern
… what I care about is I like json-ld
… if you need linked then of course you go jsonld
… I need someone to innovated with a service type and a group of white males that get to decide the future
… and it needs to be not white males

Drummond Reed: slide 93
… consolidates a bunch of things we’ve been talking about
… the core is the core
… jus like molten is the earth
… to add you need to version the spec\
… they don’t need to use them all but cant be changed
… next degree is the centralized base
… I think we could have one that both namespaces and key type services
… the point there is it’s extension through centralized coordination
… but we know how to do collision free namespaces
… do we have any choice?

Manu Sporny: i’m opposed

Drummond Reed: there’s a lot of details there and a lot are really good

Phil Archer: my career in standards begin with a massive failure
… because i was telling people how todo stuff
… the one in working is successful
… extensibility is what makes your standard useful
… it has a layer of validation
… we are going to bolt in on to what we already got
… because I need extensibility and flexibility

Eric Welton: I like the levels that sam drew
… there is this idea of what was said that we have methods that have a mechanism and we wan t a core data model that does that
… but then markus said is this a did document of myself\
… so everything is forming a nice structure
… and it gives a better definition of the trust mechanics
… and we need it to be crisp[
… and how can we formalize it into a discussion
… so how can we capture and structure that

Brent Zundel: merging did docs and vc is bad

Tobias Looker: if we look at the presentation, jose outlines a bunch of registries
… and created a process to create that core registry over time
… and manu drew a process to open claims
… and openid tokens can be created with new claims

Ganesh Annan: s/did document of myself\/did document of myself/

Ganesh Annan: s/crisp[/crisp/

Tobias Looker: I want to start creating new claims beyond the did spec that will never be created
… or Im happy for them to be semantically unambiguous
… are we expecting to updated teh core data-=model
… and they updated the context in an editor manor

Christopher Allen: one of your points is theres a distinction about people that just want the keys
… and don’t care about the establishment
… vs those that care about rotability
… and drummonds thing
… one side is in the direction of how to rotate
… and the other direction is how to record teh simplest stupidest client

Manu Sporny: I like what is hearing
… but it’s too much meta
… we need to get to some discussion
… nothing wrong with the diagram
… I’m just using this as an example
… so that green there the registry extension
… but does the green thing make it impossible?
… bu with the green stuff do you require a json-ld context
… if that’s not true we haven’t solved anything
… is that open to the JSON-LD folks
… it’s those kind of specifics, in my head before adding to the spec

Ivan Herman: first of all, I will answer
… mainly with some changes coming up
… in will be possible without complication the working group goes to a maintenance working group[
… and I know there may be version issues

Ivan Herman: but if we don’t change to structure it will be probably possible
… but what you where saying is interesting
… because there is a parallel
… . there should be a way to have a spec
… . that has a data exchange model in the document
… we have json-ld as possible
… the jsonld would refer only to one single element
… if someone wants to make use fo think linked data facility
… if no so what
… I can see something come out of this by expecting both sides
… if it is an informal registry then all bets are off
… but something like that might be possible

Tobias Looker: if you treat the green rign as the expanding core over time
… and others that will never be agreed on
… then that sorts everything

Juan Caballero: (in drummond’s diagram) on slide 93

Tobias Looker: an you update that context at the center
… and because for example
… if an open-id connect provider and they don’t publish spec
… its just informal by starting to emit things
… so I don’t know how it relates

Christopher Allen: still haven’t figured why did stuff needs to be in an endpoint
… why am I putting them all in this dag
… progressive thing to get to the key that they want
… they need to prove to me
… in bitcoin we are trying to get to a point where no pub keys are revealed

Samuel Smith: they have a combination that uses a tag based registry
… and its’a semantic overlay
… and you get the best of both worlds

11. Metadata

See slides in the deck.

Ganesh Annan: I had the pleasure of reading the long issue
… as well as the rfc logs
… slide 95 is background
… just want to say dan you’ve touch on the things i’m talking about
… see slide 97
… slide 98 did doc explained
… the way I look at that is theres an object and graph model that relates to that did
… slide 99
… it is the output of calling DID resolve on some did
… and we did that to give full intention to that did method
… slide 100
… we can not make assumptions of how its rooted in a database
… a did doc is not a file in a file system
… so when think about did document created
… slide 102
… this can be though of as the same way as a date header
… the date that’s put on the header and response
… I think that’s the way we’re supposed the think about it
… slide 103
… slide 104

Ivan Herman: I know it will sound like bike shedding
… isn’t it time to use something a different term for a DID document
… the effect of using the term “did document” leads to the discussion we’re having now

Christopher Allen: there is some history
… there was a DDO
… then we started calling it a DID document
… in my world it needs to be created

Oliver Terbu: if you read the date field of http
… wouldn’t this break the proof of the did document
… if they protected it with the proof

Drummond Reed: I want to make the point that you said anything in the did doc must describe the subject
… there’s information about the did subject
… should we separate that
… create date and update date
… are we talking about when the tea pot was made and broken or not
… how do we separate that

Joe Andrieu: couple things
… need bear witness
… it could be a bout a group which I’m a member
… I don’t like arbitrarily sucking everything up because i’m not my did
… is the controller in charge?
… then that’ metadata
… the reason I said on that update date
… if a controller wants to update the date and it took 3 days for bitcoin to get the transaction
… did the did controller say it

Jonathan Holt: +1 to Joe

Markus Sabadello: I wanted to say something similar
… in the resolution spec
… in the resolution there is the resolution result
… to me whats in the did doc can be different for each resolution process
… the metadata about the person may be different
… changes only when the controller updates it
… the second thing i wanted to say about created
… I disagree with what gannon said
… I think the did document is create when the did is created
… it may not be stored as a file
… and the resolver retrieves it and constructs it

Kenneth Ebert: +1 to markus’ comments

Jonathan Holt:
… I think time is relative
… the time may be relevant
… was an issue with the classic
… by jumping ahead in the timestamp
… and that should be considered

Manu Sporny: wanted to +1 drummond
… there are two things were talking about
… I think it’s interesting that joe and I disagree
… I don’t think it has any affect on the decision
… and I think markus is write that your framing of whats a crated date is spot on
… that did doc that this group is creating
… it has an identifier
… that I think by and large has information asserted by the did
… and it becomes obvious
… markus example is outside since the controller didn’t make that assertion
… this is info asserted by the controller
… and there is a clean break about what’s data and metadata

Justin Richer: what I observe here
… is that people want to make statements about two things
… the document and info that got the document here
… and we don’t have a clear way to express that
… and people are getting upset about that
… like the created_at

Kenneth Ebert: +1 to Justin_R’s categorization of the data/metadata

Justin Richer: this is something that is something that needs to fit with the resolution process
… we might be able to define things about the did doc
… and however that comes back is up to the method
… and theres’ lots with response headers

Phil Archer: I like the thing about how the did doc isn’t real
… and so I wonder if we can state in the spec
… and say it’s not appropriate
… and if you need software that depends on that it’s wrong
… nobody has asked us about the did doc unless you ask you get redirected to the service
… nobody asked about metadata about that
… I think this idea that the did doc that only treats it in that way

Daniel Burnett: just going to say
… wonder if the did subject is the uri resource
… keep goin back to rfc 3986
… the resource doesn’t need to be real
… so did subject and resource doesn’t need to be the same thing
… I like the idea of being clearer about separating process
… from information
… was looking a did info a nd did presentation
… clearly there are different levels

Drummond Reed: first point I want to respond to dan
… we do say in the spec the did identifies the did subject
… bucket 1
… not sure how the did subject could
… there’s a metapoint about identifying the did subject

Daniel Burnett: a did has a resource and that could be anything

Justin Richer: to clarify my statement from earlier for the notes, I actually mentioned three things: data in the document, data about the document, and data about how the document got there

Drummond Reed: I want to address what just says by saying I agree with him
… metadata describes data
… its really just a graph
… you put a node in the graph of the document
… and under it we put al metadata about the document
… its not rocket science

Phil Archer: +1 to drummond

Drummond Reed: we’re not even sure we’re talking about the did subject

Samuel Smith: q

Markus Sabadello: with regard to the resource
… . sometimes we treat the did as an identifier
… and sometimes we treat as a subject.
… final thing I wanted to say is that I agree that it’s inline with architecture tor return meta-data
… I just don’t like did resolution response

Yancy Ribbens: .. which sounds like client server protocol

Ganesh Annan: +1 to DID Resolution Result

Jonathan Holt: Time in blockchains is relative: i.e. The timestamp of bitcoin block #180966 is 2012–05–20 23:02:53

Jonathan Holt: The timestamp of bitcoin block #180967 is 2012–05–20 23:02:13.

Oskar van Deventer: some of this is confusing
… what is the purpose fo a did document?

Justin Richer: a lot of people are already deploying
… and coming in to the group we realize there are no definitions
… I think there are 3 different resources
… the uri as a subject
… once you treat as url
… you’re not getting back a subject
… if theres a service end-point, you only get back what’s serialized and returned

Tobias Looker: if you put a resolver into jus a uri
… is that did itself considered a URL?
… which in my mind is an assertions about the subject by the did controller

Joe Andrieu: I think you should get back the whole document

Daniel Burnett: you may not agree with me
… want to talk about making it rain
… and if someone else asks what it identifies
… it identifies a subject
… the did subject might be the sku
… so what is the resource that I’m manipulating?
… there might be a did for the sku
… I would draw a distinction between the did subject and the resource
… if the did subject is me, and you want to call me it’s dan
… I don’t have a phone in my brain
… and youl call some number that i’m going to answer

Brent Zundel: we are having trouble defining the metadata about the data
… we need to figure that out before we talk about metadata
… we need to come to some agreement

Daniel Burnett: maybe look at items in DID doc and list where they come from -

Drummond Reed: id love to have time to draw another diagram
… there are two dots

Daniel Burnett: asserted by DID controller, resolution process, etc.

Drummond Reed: the did is the label on that arc
… the did subject is whatever that dot is on that arrow
… and for any controller they define what that dot is
… and if dan says its pointing at the sky, it’s whatever dan think the sky is
… in someway it gives us the ability to describe what we think something is
… the first dot is the did controller
… there dot one
… point two is JoeA as usual is right
… I want to clarify what he’s correct about
… when markus and I collaborated
… and if we get to it we have a proposal of how to clarify that
… the did document is never the subject
… from a web representation, because it’s metadata, we have this thing markus pointed out
… it’s a resource on the web
… the DID itself is a uri and not a URL
… if you want to identify the did document you add one character. or proposal is to add forward slash

Eric Welton: +1 to all that
… the thought I had was the did could be anything
… and if I create a document outside of did land that describes the seating chart, that’s how it will be in the did document
… I may want you to add information about it
… and I don’t need heavy crypto
… and I say if I created a did
… I would have control over that and I don’t need to establish authority over that
… it’s more like a uuid
… a lightweight did

Manu Sporny: I’m concerned this is http range 14
… http range 14 is a discussion ongoing for 20 years
… there is no correct answer and thousands of engineers haven’t found an answer

Phil Archer: See HTTP Range 14 in Wikipedia

Drummond Reed: the Wikipedia page on HTTPRange14 is highly recommended

Jonathan Holt: issue #14. https://www.w3.org/2001/tag/group/track/issues/14

Manu Sporny: the way you escape is someone produces some definitions
… and if its’ good enough for a few members, then we move on
… you should read about it

Ivan Herman: if you have a url against a resource, and the resource is a book, what exactly are you referring to?

markus sabadello2: Last year we spent several weeks discussing DIDs and httpRange-14 during the DID Resolution calls. A summary is here: https://docs.google.com/document/d/1gSUP9DEp7IO8jyNDsVnC-7Ed6PjbMRxl89nGYUoWoeI/

Joe Andrieu: I think we have a proposal
… I think it resolves what we mean
… but lets get the proposal
… I want to touch on how we instantiate identity as attributes
… what clicked for me is there’s a problem around formal vs informal identity
… whatever the controller defined may not know what it is yet
… I don’t need a legal form of identification

Jonathan Holt: “Tim’s argument that HTTP URIs (without “#”) should be understood as referring to documents, not cars”

Joe Andrieu: i’m just trying to figure it out

Phil Archer: don’t do the slash thing
… a query I want the did doc or don’t
… especially if it’s just one char

Drummond Reed: what we did want to do to address manus point
… and we spent 15 years working on the semantic web problem
… we hadn’t said there’s a huge case for a type that’s abstract
… and realized there is a did
… and a definition can evolve over time and that we pull semantic naming over dids
… and fantastic we can get to more sophisticated ways about semantics

Drummond Reed: if there are additional buckets, we can agree on the metadata

Christopher Allen: hopefully dids will never be seen by a user
… but another challenge where i’ve dealt with the slash at the end
… that will translate to xml
… the pattern we’ve seen has been challenging

Tobias Looker: was going to make the point about what the difference would be
… trying to tease out the details to the developer
… and to resolve it you need to add a slash
… would not give merit by confusing the developer

Ganesh Annan: want to make sure this issue moves forward]
… feels like there’s some precursor about what gets put in a did document
… and if theres agreement I take input and try to bring it back to the group to resolve

Drummond Reed: +1 to Ganesh’s proposal of how to move forward

Justin Richer: +1

Markus Sabadello: +1

Samuel Smith: I used a functional description
… we have established did documents
… then you go to binding of identify and you have circular definition
… you first have to verify the did document has not been tampered with
… and we don’t have a clear understanding of what a did document is
… anything in my locus of control is in my locus of control
… any information that I put information in
… when I see these discussions about metadata I want to pull my hair out

Manu Sporny:

  1. A DID is an identifier that identifies a resource.
  2. Dereferencing the DID gives you a DID Document.
  3. A DID document is the resource that is associated with a decentralized identifier (DID).
  4. A DID document contains information asserted about the DID by the controller of the DID.
  5. Any information that isn’t asserted by the controller of the DID (i.e. metadata about the DID Document) is placed elsewhere.

Samuel Smith: because we don’t have a way to know if its been tampered with

Manu Sporny: not saying this is the right language but we should go through that on github

Daniel Burnett: no to number 3

Daniel Burnett: we MUST NOT make the DID document the resource

Daniel Burnett: For the minutes, manu confirmed that #2 meant to say “Resolution” instead of “Dereferencing”

Markus Sabadello: I wanted to say a few more things about the slash
… some times we treat is and identifier for the document
… when we use a fragment
… some of this is reflected here
… the first one makes it sound like and identifier for the subject
… 3 sound more like identifier for did document
… are we ok with sometimes we use for both
… usually theres a very strong reaction
… one for subject one for did doc

Kenneth Ebert: I think it’s useful to talk about what types
… are there other types

Drummond Reed: Drummond is NOT okay with conflating the resource that is the DID subject and the resource that is the DID document

Daniel Burnett: along the lines of what ganon says
… look at them and see where they come from
… and what we want is the buckets
… start with the buckets and say how does that get there
… unless we look att the specifics were never going to reach a decision
… I’m with markus
… the document is not the resource
… its information about the processing
… I’m willing to say its about the subject

Drummond Reed: Drummond wants to argue passionately that the root of the DID document is the DID subject, and that all direct properties of the root describe the DID subject. To describe any other “bucket”, add another property to the DID document that we define in the spec represents another resource (e.g., the DID document), and then have subproperties of that describe that resource.

Drummond Reed: Drummond also reminds himself to talk about a third role in addition to “DID subject” and “DID controller”, which is “key controller”

Joe Andrieu: 1 and 3 are wrong
… human is not a resource the way the web thinks about resource
… so I think the way you use a tool can define that tool
… a hammer could be a tool or a weapon
… it echos what I said earlier that we don’t have clear distinctions
… if you auth it doesn’t mean you control the document

Sam Smith: we have a circular definition

Drummond Reed: discovered a new extensibility section
… want to put in a plea to keep the did subject as just the resource identified by the did
… the uri url urn distinction
… we need to identify the way things are on the web

Daniel Burnett: Disagree STRONGLY with Joe. Don’t confuse the group by suggesting that return of an artifact somehow just makes it the resource. This may be theoretically interesting to say, but it just turns the DID into a normal URL that references a file called the DID doc.

Drummond Reed: where it gets tricky is they way you want to identify things
… then at least we can take a point and say what is identifying is the subject or any other bucket
… if you look in the abstract data model, and the root of the tree is a subject
… we are going to establish properties
… theres a did subject, controller and a third role
… someone could auth using data that’s not the subject or controller
… and I call it the third role
… the key controller

Christopher Allen: so I really want to limit the purpose to as minimal as necessary
… we use a backslash for one and forward for the other
… I get more territory for other stuff of developers putting in PII
… you want to do the min for the business purpose
… if its a control app that allows cap to work
… that very first step is all I want

Phil Archer: #4 contains info about the did, and surely it’s about the did subject
… we need to be clear about what we’re describing
… that’s what range 14 ended up with
… and when you resolve that you end up with a 303
… you need to be more explicit about that
… I think drummond came up with 3

Joe Andrieu: suggested fix for 4: A DID document contains information asserted by the controller of the DID. separately, we have the issue of limiting the data in the doc

Phil Archer: and drummond came up with a 4th

Ivan Herman: if I have a did that I established for myself,c and I use it
… to make assertions about my name (not only within the DID document)
… no that did is only referring to me and never anything else
… that identifier will have it’s own life, for example like on the web

Manu Sporny: that was the discussion I was hoping for
… no chair tossing yet
… at least we can have a discussion about that
… want to discuss semantic ambiguity
… developers always screw it up, they only copy the base.
… we have it working well

Brent Zundel: this WG is awesome
… we’ve talked about a lot of things to do
… this last 1.25 hours has made us look at different things. back when we talked about DDOs we looked back and decided that want right
… lets get a PR that gets a refinement about what we did