07:17:47 RRSAgent has joined #did 07:17:47 logging to https://www.w3.org/2020/01/30-did-irc 07:17:48 RRSAgent, make logs Public 07:17:49 please title this meeting ("meeting: ..."), ivan 07:17:56 Chair: brent, burn 07:19:27 gannan has joined #did 07:20:01 yoshiaki has joined #did 07:21:17 Meeting: DID Working Group F2F, 2nd day 07:21:41 Agenda: https://tinyurl.com/didwg-ams2020-agenda 07:21:53 Meeting slides: https://tinyurl.com/didwg-ams2020-slides 07:22:45 yofukami has joined #did 07:26:55 present+ 07:30:23 ivan has joined #did 07:30:46 tplooker has joined #did 07:31:41 yoshiaki has joined #did 07:31:54 brent has joined #did 07:32:07 present+ 07:32:16 scribe: markus_sabadello 07:32:39 present+ 07:33:59 Slides and Audio: https://zoom.us/j/5593214233 07:34:09 scribenick: markus_sabadello 07:35:37 ewelton has joined #did 07:37:21 ivan: (going over logistics of afternoon activity) 07:37:23 Eugeniu_Rusu has joined #did 07:38:37 charles has joined #did 07:39:08 dezell has joined #did 07:39:19 brent: Yesterday we got a lot done, we have more today; hopefully leading to some resolutions 07:39:51 brent: This morning we will talk about interoperability, what does it mean, and what levels; hopefully come to decision what kind of interoperability we want 07:39:53 present+ 07:39:56 present+ 07:40:04 brent: Then we talk about interplay between interoperability and extensibility 07:40:07 present 07:40:11 brent: After that we work on JSON PRs 07:40:15 present+ 07:40:25 brent: Then we talk about next steps for the spec 07:40:28 SamSmith has joined #did 07:40:31 Oskar has joined #did 07:40:43 brent: During lunch I will present on ZKPs 07:40:59 brent: After that we will have a boat tour on the canals 07:41:18 juan_caballero has joined #did 07:41:30 Oskar has joined #did 07:41:39 brent: (Going over dinner logistics) 07:41:57 Oskar has joined #did 07:41:58 present+ 07:41:58 zakim, who is here? 07:41:58 Present: markus_sabadello, brent, yoshiaki, ivan, ChristopherA, Eugeniu_Rusu, Oskar 07:42:00 On IRC I see Oskar, juan_caballero, SamSmith, dezell, charles, Eugeniu_Rusu, ewelton, brent, yoshiaki, tplooker, ivan, yofukami, gannan, RRSAgent, Zakim, markus_sabadello, 07:42:00 ... presenter, chaals, burn, llorllale, wayne, deiu, rhiaro, ChristopherA, bigbluehat, jfishback, Travis, hadleybeeman, dlehn, manu, dlongley, yancy 07:42:17 present+ 07:43:03 present+ Eugeniu_Rusu 07:43:41 Justin_R has joined #did 07:43:56 Joachim has joined #did 07:44:06 present+ 07:44:07 present+ 07:44:11 present+ 07:44:12 present+ 07:44:13 jpresent+ 07:44:14 ken has joined #did 07:44:19 present+ 07:44:21 present+ 07:44:28 drummond has joined #did 07:44:30 Carsten has joined #did 07:44:34 present+ 07:44:38 phila has joined #did 07:44:45 present+ 07:44:53 present+ 07:45:17 selfissued has joined #did 07:45:21 present+ 07:46:22 burn: Everyone type present+ if you're participating in the meeting; just being logged in to IRC is not enough 07:47:46 burn: Still looking for scribes for tomorrow afternoon sessions 07:48:52 brent: Mike and Manu will present 07:49:04 Topic: Levels of Interoperability 07:49:33 manu: Mike and I will run through some things to understand about interop; often we don't define what it means 07:49:49 manu: Will go over types of interop, then Mike will go over how you get to those levels of interop 07:49:49 q+ 07:50:18 manu: Kinds of interoperability: Not necessarily a layered thing, just different types of interop 07:50:38 manu: First option: No interop at all (we wouldn't be here if we wanted that) 07:51:11 burn: Making this statement is very important. 07:51:22 manu: As we discussed yesterday, this confuses the market and everybody suffers 07:51:46 manu: Next step: Interop at the data model layer, you got some abstract data model, people agree on types of things we want to write down in the spec. 07:52:18 manu: This is not ideal, there are different ways of implementing and deploying 07:52:21 q+ to Where does different cryptography (curves [eg. 25519/sec256k1], signature algorithm [eg rsa/ecdsa/Schnorr], cryptographic proofs, 07:52:26 manu: We'd like something better than that 07:52:40 manu: Next layer: You interop at the data model layer, and you interop on some basic syntax layer 07:52:52 manu: This is where discussions about JSON,JSON-LD, CBOR, etc. come in 07:52:57 nicole has joined #did 07:53:04 manu: In VC work, we achieved data model interop, and basic syntax interop 07:53:20 manu: Then there are different kinds of interop that you can mix in there, nice to have 07:54:02 manu: Interop on extension mechanism. One aspect of a good spec is to have ways for people to use it for their own use cases (via extension mechanisms). 07:54:25 manu: Interop on canonical form. Is there a canonical form of the data model, is there a stream of bytes? 07:54:45 manu: Abstract canonicalization and syntax-based canonicalization. Do you always serialize it in the same way 07:55:10 manu: Syntax-based canonicalization is interesting if you want to do digital signatures. 07:55:20 manu: You have a data model, and there is ONE way to serizalize it. 07:55:41 manu: Interop on behavior. Not just data model and syntax, but the spec also defines what you can do with it. 07:55:58 manu: People do something with the data, and you get the same result 07:56:10 manu: With the DID Core spec, we expect CRUD operations for all DID methods, we expect interop there. 07:56:16 ack ChristopherA 07:56:16 ChristopherA, you wanted to Where does different cryptography (curves [eg. 25519/sec256k1], signature algorithm [eg rsa/ecdsa/Schnorr], cryptographic proofs, 07:56:33 ChristopherA: I think there is a missing section: What are the forms of cryptography that is being used? 07:57:33 ChristopherA: When we did our Wyoming interop project, couldn't find a combination of curve, signature suite, canonical method, selective disclosure that worked consistently across different implementations. 07:57:38 q+ 07:57:40 manu: Any other kinds of interop? 07:58:23 kaliya: At IIW there was an SSI stack diagram of different layers and protocols at each layer 07:58:26 ack ivan 07:59:01 ivan: Interop at the user interface level, and the tools that are being used. 07:59:25 q? 07:59:26 is this oliver's stack diagram from IIW that Kaliya mentioned? https://medium.com/decentralized-identity/the-self-sovereign-identity-stack-8a2cc95f2d45 ? 07:59:27 q+ 07:59:35 ivan: We will have tools that implement DIDs, and there will have to be some conceptual interop between those tools 07:59:47 https://miro.medium.com/max/1227/1*4zUczSBaVH-8qilvK4nKwQ.png 07:59:53 ivan: Out of scope for this WG, but some other group may look at this 07:59:58 identity_woman has joined #did 08:00:00 ack phila 08:00:04 present+ 08:00:04 https://medium.com/decentralized-identity/the-self-sovereign-identity-stack-8a2cc95f2d45 08:00:14 q? 08:00:47 phila: One of the ways how you will share DIDs will be via optical QR code. How will people know what the QR code will do? You need some visual indication 08:01:21 ChristopherA: Related to that is the wire forms. Do you support QR codes, do you use UDP, what transports do you use. 08:01:32 selfissued: Interop on protocol messages 08:02:35 (showing SSI stack diagram) 08:02:53 manu: Mike will now talk about how to get to those levels of interop 08:03:14 selfissued: Will talk about experience how you can get implementations of specs to interoperate with each other 08:03:31 selfissued: This is informed by the process we used for OIDC, JWT, etc 08:04:02 selfissued: In the early beginning, you can get together at IIW, or virtually, etc., and you try to use your implementations together in the ways that the spec intends 08:04:27 selfissued: E.g. manu wrote a relying party, and I wrote an identity provider. Now we can try if they can communicate successfully at all. 08:04:42 q? 08:04:44 q+ 08:04:49 selfissued: As you do this, you will find some thing that work, and some things that don't work. Either you did things differently, or your implementations are incomplete 08:05:03 selfissued: This gives you data what works and what doesn't, and you can improve things. 08:05:51 selfissued: The next level could be creation of a test suite that attempts to test some known parts of the protocol, and you run your implementation against the test suite. Again you learn what works and what doesn't. You also learn about bugs in the test suite. Then you iterate and fix things. 08:06:26 selfissued: Next level is you take a test suite, and you morph it into a formal certification tool, where a WG defines a set of tests. If you successfully test all of them, you get a certification mark. 08:06:54 selfissued: In our OIDC work, we got a lot of feedback, the end result is that certified implementations tend to work together much more seamlessly 08:07:26 selfissued: Difference: In the interop test suite, you can implement the parts you like and leave out the rest. OTOH to reach a certification level, you have to implement a minimum bar. 08:07:32 ack burn 08:08:06 burn: Regarding certification program: For most WGs I have been in, that has been out of scope of the WG, it better fits into an industry consortium. It is highly political. 08:08:19 q+ to note that DIF has noted they want to do certification, as a data point. 08:08:24 burn: It's one thing to say "the spec contains a list of features", it's another thing to say "your implementation has failed". 08:08:45 ack manu 08:08:45 manu, you wanted to note that DIF has noted they want to do certification, as a data point. 08:08:59 selfissued: Yes there are different certification models. 08:09:22 selfissued: One is third party certification. You pay a large amount of money to an independent organization to configure and run the code 08:09:24 q+ to say that W3C is not an enforcement body 08:09:42 selfissued: E.g. Microsoft got a SAML certification, product got better because we did that 08:10:06 selfissued: In OIDC we said that we wanted certification, but using a third party is a lot of work and costly 08:10:48 q? 08:10:54 q+ to comment about reliability of self certification with no enforcement 08:11:00 selfissued: Instead we tried another model: self-certification. You run the tests yourself and submit all logs for public inspection. It's kind of like the open-source model. Not everyone will read my logs, but the point is that everybody could read them 08:11:47 selfissued: Another aspect is making legal statements if a third party certifies 08:12:01 q 08:12:07 q+ 08:12:32 manu: Certificaiton is something that W3C has traditionally not done. DIF has more recently said that they are interested in running certification programs. W3C would produce specs, and a different body would do certification 08:12:33 q+ to talk about self-certification 08:12:48 q- 08:13:25 selfissued: Virtual cycle between testing and specification work. Interop testing can expose implementation bugs as well spec bugs. 08:13:47 q+ to emphasize the role of CR and also comment on certification 08:13:48 selfissued: Developers will get involved early and often, they can tell us what is good and what is bad 08:14:13 selfissued: Interop testing can expose all of that. You can interop, test, fix the code, fix the spec. 08:14:39 selfissued: Ideally you do several rounds of this. Do a snapshot of the spec, get developer feedback, change spec until it's interoperably implementable. 08:14:58 selfissued: What do we want to test to improve interop? 08:15:06 selfissued: Test the MUSTs and SHOULDs 08:15:39 selfissued: Test the positive cases (the paths that work), but also at least as important to test the negative cases (what does your implementation do if it encounters bad input) 08:15:52 q+ to comment on data format vs. protocol 08:16:23 selfissued: Example in the SAML work. More than 50% in a specific situation accepted a bad signature. All the positive cases worked, but the negative cases worked too 08:16:38 (laughter) 08:16:47 selfissued: Make sure your implementation errors and logs the error 08:17:20 q+ to talk about extensibility points, too 08:17:39 selfissued: You can to test uses of the extensibility points. Deployments will often specialize their implementations by using the extensibility points. You want your tests to check if nothing breaks if extensibility points are being used. 08:18:00 q+ to describe fallacy of strict issuance and liberal acceptance 08:18:21 selfissued: Example: In OAuth, any request value you don't understand must be ignored. This let's you do many extensions where you send extra request parameters. You need test cases that inject arbitrary additional values and check if implementions successfully ignore that. 08:19:11 selfissued: If there is a state machine in your specification where you can progress between states, you want to have tests that the succession of states implemented by the code is the expected succession. 08:19:25 gannan has joined #did 08:19:38 selfissued: E.g. if you do a write operation, then you do a read operation, test that you get the correct result. 08:19:51 q 08:20:36 selfissued: Regarding burn's point about political aspects of certification: You want test definitions to be public. They correspond very closely to the specification. There have to be objective reasons why the test exist (ideally pointing to a specific part of the spec). 08:21:33 selfissued: You keep everything in an entirely binary pass/fail basis. All have to run the same tests to get the same certifications. No exceptions are made for dominant player in the market. Even if you have something in production, you may not get certification. 08:22:26 ack burn 08:22:26 burn, you wanted to say that W3C is not an enforcement body and to comment about reliability of self certification with no enforcement and to comment on data format vs. protocol 08:22:27 mshea has joined #did 08:22:28 selfissued: If you do or do not include a test, that is the result of a working group consensus decision. The WG represents the industry, it serves as a check and balance that the tests are fair and complete. 08:22:29 ... and to describe fallacy of strict issuance and liberal acceptance 08:22:35 q? 08:23:26 burn: I worked for a company to make sure it was 100% compliant. 08:23:56 burn: W3C is not an enforcement body. It depends on what your industry wants and needs. A third party is better as an enforcement body. 08:24:34 burn: Reliability of self-certification is not always as good as it sounds, even if all results are public. 08:24:38 q+ 08:25:01 burn: We define a data format and not a protocol. We cannot stray too far into how our document formats are used. We had a similar situation in the VC WG. 08:25:12 burn: As we get further along, we have to keep this in mind. 08:26:06 burn: The IETF used to say be strict in what you issue, be liberal in what you accept. IETF doesn't say that anymore. It now says you also have to be strict in what you accept. Otherwise implementation get lazy, things don't work, and security issues follow. 08:26:15 q- 08:26:22 burn: Agree that it is important to test negetive cases. 08:26:53 q? 08:26:53 selfissued: In a data format, there are things you can test and things you can't test. Example: In DID document, some things have to be present, some things have to follow a certain format. You can test this. 08:27:01 q+ 08:27:04 q+ 08:27:39 selfissued: Lazy example: In JWK, key values are encoded as base64url strings. It turns out that Google used to publish their keys in base64 encoding, not base64url encoding. 08:28:06 selfissued: Some implementations that read the keys worked (they accepted the value even though the encoding was wrong), other implementation didn't work. 08:28:19 selfissued: Google eventually fixed their keys, this was a success of the certification program. 08:29:22 selfissued: Example of OIDC Financial API. They require certification every 6 months. When that we run by OBEI, the gave certifications with footnotes, saying that bank X implemented most of it, but they got client authentication wrong. They were certified, even though something didn't work. 08:29:38 selfissued: Market interest said everybody passed, even though they were not interoperable 08:29:49 q 08:29:55 ack Justin_R 08:29:55 Justin_R, you wanted to talk about self-certification and to talk about extensibility points, too 08:29:57 selfissued: Later this was changed to not use footnotes; it either works or it doesn't. 08:30:18 Justin_R: You can run the test suite yourself without going through certification program. 08:30:19 zakim, close the queue 08:30:19 ok, brent, the speaker queue is closed 08:30:26 q+ 08:30:49 Justin_R: Newer versions of the test suites is more easily packaged, you can run it on a local dev environment. This is very important. All test suites must be open source and publicly available. 08:31:12 Justin_R: Regarding extension points, testing those will be very important to this group in particular, given lots of discussion about extensibility. 08:31:34 Justin_R: If you're a JSON-LD process and you see something in the doc you don't understand, you have to react correctly. 08:32:42 Justin_R: The Java test suite doesn't use an OIDC library, since you have to test bad things (bad signatures, etc.) to make sure that things are exercise fully. This is easier to do without a library. Just write custom tests for everything. 08:34:06 Justin_R: Regarding public availability of logs, this is very valuable. If you look at logs of Azure test suite, they pass, but only on single tenancy, therefore Microsoft passes. Other tenancies are different. 08:34:27 ack ivan 08:34:27 ivan, you wanted to emphasize the role of CR and also comment on certification 08:34:32 burn: A company may get certified for something they built, but the product they sell may be something different 08:34:45 q- 08:35:04 ivan: One points about certification: W3C has had several problems where it developed things that turned out to be in competition with what members wanted to do for money. 08:35:28 ivan: W3C long ago had a browser implementation. Members didn't like that because they wanted to have their own business around that. 08:36:02 q+ 08:36:32 ivan: How does the spec CR phase fit into this picture? In this testing phase, formally the emphasis is different: When we test, we need to submit a report to the management. Without that we cannot get to a recommendation. 08:36:43 ivan: The primary function of the CR phase is testing. 08:36:45 q 08:36:50 W3C CR goal is to test the spec, not the implementations 08:37:04 ivan: Make sure the spec is "implementable". Must have at least two independent implementations. 08:37:40 ivan: From W3C point of view: Brave, chrome, vivaldi don't count as separate browser implementations. 08:38:08 ivan: We have to report that every features must all be implementable, must be proven by concrete implementations. 08:39:07 mshea has joined #did 08:39:11 chaals has joined #did 08:39:18 ivan: Agree with Justin_R's point about self reporting. From W3C point of view, if someone comes in and produces tests, it helps them in the public image. But it's not about public image, it's about understanding that we did the right thing with the spec. 08:39:38 ack ChristopherA 08:40:22 ChristopherA: I have history here with SSL/TLS. Three intertwined problems: Early on you couldn't request a certificate unless the code had security reviews. 08:40:28 JoeAndrieu has joined #did 08:40:35 present+ 08:40:40 q 08:40:44 ChristopherA: We looked at code for max. 8 hours. If we didn't find any problems we let it pass. 08:40:56 q+ 08:40:57 ChristopherA: We usually found serious problems within an hour or two. 08:41:14 ChristopherA: We got feedback that we can't allow >50% of people to fail. 08:41:32 ChristopherA: Eventually, everybody ended up using only openssl. 08:41:43 ChristopherA: There were non-free implementations that came with support 08:42:10 ChristopherA: Tragedy of open source. Tragedy of the free. Security certification is harder than data certification. 08:42:47 ChristopherA: TLS 1.3 should have been done in 2003. Got done in 2018. 08:43:05 ChristopherA: Keep in mind that once we do DID 1.0, there may not be an opportunity to do DID 2.0 08:43:14 Topic: Discussion 08:43:27 q+ 08:43:27 q+ to ask about method interop 08:43:34 brent: Let's discuss do we want to have interop. How much? 08:43:40 q+ to ask about method interop 08:43:41 q+ 08:43:44 q+ to ask about method interop 08:43:46 q+ to ask about method interop 08:43:47 q+ 08:43:54 zakim, open the queue 08:43:54 ok, brent, the speaker queue is open 08:43:55 q+ to ask about method interop 08:43:55 q+ 08:43:57 gannan has joined #did 08:43:58 q+ 08:44:11 SamSmith has joined #did 08:44:17 q 08:44:47 selfissued: Regarding centralized vs. diversity. We intentionally made the barrier to certification low enough to make it available also to open source. 08:45:21 selfissued: In OIDC, over 100 certified implementations. 08:45:25 selfissued has joined #did 08:45:27 q+ 08:45:30 ack JoeAndrieu 08:45:30 JoeAndrieu, you wanted to ask about method interop 08:45:32 present+ 08:45:32 brent: Which of the kinds of interop do we want 08:45:50 JoeAndrieu: Missing topic is method interop, we should talk about whether we want that 08:45:53 q+ 08:45:54 tplooker: what do you mean by that 08:46:20 JoeAndrieu: We don't have any DID method specification under our control. So we can't test/certify compliance of DID methods 08:46:58 q+ 08:47:08 JoeAndrieu: Many conversations I've heard: We are going to use one DID method. This doesn't mean it will interoperate with another DID method. 08:47:39 burn: Let's go over the types of interop and get opinions on which ones we want 08:48:08 burn: Interop on data model? 08:48:14 (everybody raises hand) 08:48:26 burn: Interop on data model and basic syntax? 08:48:33 (everybody raises hands) 08:48:43 burn: Interop on extension mechanism? 08:49:01 (most people raises hands) 08:49:05 burn: Any concerns with that? 08:49:16 ChristopherA: Extension mechanisms, what parts? Maybe some yes, others not 08:49:44 burn: Interop on canonical form? 08:50:02 selfissued: If there is a canonical form, should we interop? 08:50:44 manu: In VC we defined JWTs and LD signature. So people interop'ed on different things. Is that interop or not? 08:51:15 burn: Interop on cryptography? 08:51:20 drummond: What does this mean? 08:52:16 brent: If two implementations agree on the signature type, one can produce it, the other can verify it 08:52:21 burn: Anyone disagrees? 08:52:26 (nobody disagrees) 08:52:41 tplooker: The data model needs to be able to express the type of signature 08:53:22 burn: Is there any other aspect of interop we need to ask about? 08:53:43 selfissued: Crytographic algorithms are extension points. New ones will get added, old ones will be removed. 08:54:00 burn: Anyone disagrees? 08:54:06 (nobody disagrees) 08:54:29 q 08:54:33 ChristopherA: How many people feel extension mechanisms are very orthogonal aspects. I feel that's the case 08:55:19 JoeAndrieu: TO the extent crypto is an extension point, we may have no interop except between implementations that support the same extensions. Are there any crypto suites that we will test for interop? Is there a subset of the extensible world that we want to test on? 08:55:38 tplooker: E.g. in JWT there is a subset of crypto suites that must be supported, but extensions are still possible. 08:55:41 q? 08:55:50 q- 08:55:57 q- 08:56:15 burn: Let's try to get some more high level comments about other items 08:56:39 manu: Interop on behavior, user experience, transport, protocol are out of scope. 08:57:20 manu: Test MUSTs and SHOULDs, the ones in the spec apply to data model, not behavior. But there is also a gray area. 08:57:31 brent: We also specify how methods get implemented. 08:58:09 burn: Because we specify how methods need to work, therefore there will be some behavioral statements that are testable 08:58:35 burn: Interop on user experience? 08:58:42 (agreement this is out of scope) 08:59:31 q 08:59:40 q+ 08:59:47 q+ to talk about UX & interop 08:59:53 Justin_R: even if it's not in scope to specify and test, it's going to influence every decision we make. what's available to the user, how the user is presenting things. We all bring our personal biases what kinds of interactions are avialable. 08:59:59 q+ 09:00:09 Justin_R: We have assumptions based on what we're building 09:00:31 burn: There may not be testable interop on user experience, but we absolutely must consider user experience. 09:00:37 chaals has joined #did 09:00:48 burn: Reaching edge cases that require much discussion. 09:01:04 JoeAndrieu: Can we use the queue again 09:01:11 burn: Trying to get additional quick results 09:01:28 q- 09:01:34 q- 09:01:38 q- 09:01:50 Zakim, clear the queue 09:01:50 I don't understand 'clear the queue', Justin_R 09:02:08 q= 09:02:10 q= 09:02:25 queue= ... 09:02:35 ack ... 09:02:35 ack .. 09:03:44 ivan: Based on the experience of other groups, as soon as we have a spec, we need to start working on test suites. This takes more time than you think. 09:03:58 manu: A test suite exists. A framework is there, but tests are outdated. 09:04:22 burn: Much more to discuss, but we got some agreement on basic statements. 09:04:28 oliver has joined #did 09:04:34 present+ oliver 09:04:39 burn: Chairs believe we've had enough of this conversation to now move on to the big topic. 09:04:56 burn: JSON, JSON-LD, abstract data model come down to extensibility and interoperability. 09:05:17 burn: Now we can start a discussion on this key topic. That's why the next topic is "extensibility and interoperability" 09:05:38 burn: manu has some proposals that result from various conversations with WG members 09:05:57 burn: manu presenting this is an attempt to record something that the group might be able to agree to 09:06:00 Topic: Extensibility and Interoperability 09:06:10 burn: This is not what manu wants, but what manu thinks we can agree on. 09:06:36 burn: (short break now) 09:06:45 Topic: Extensibility and Interoperability 09:21:29 Justin_R has joined #did 09:21:41 drummond has joined #did 09:21:46 yofukami has joined #did 09:22:08 selfissued has joined #did 09:22:10 present+ 09:22:19 oliver has joined #did 09:22:19 burn: Resuming the meeting. Please everyone respect the queue. 09:22:23 present+ oliver 09:22:29 present_ 09:22:33 Topic: Extensibility and Interoperability 09:22:38 s/present_// 09:22:42 present+ 09:22:55 manu: We are going to attempt two proposals based on conversations on these topics 09:23:08 manu: The purpose is to try lower the tension 09:23:19 manu: Proposal #1 09:23:49 manu: I believe everyone was onboard to have an abstract data model that can be cleanly represented in JSON, JSON-LD, CBOR. there will some graphical depiction of the abstract data model. 09:23:54 q+ 09:23:58 q+ 09:24:06 q+ 09:24:21 q+ to comment on the assumptions this proposal makes (and make it clear) 09:24:25 manu: The extension mechanism in the spec will be a registry. People have been asking for it. The registry will have to be managed by the Working Group (or maintenance group). This means more process. 09:24:46 manu: Levels of interop we want to get to: We want to have interop between JSON and JSON-LD 09:25:15 manu: In order to add an entry to the registy, and extension author has to provide a spec AND a JSON-LD, in order to keep compatibility with the JSON-LD world. This does NOT mean you have to use @context 09:25:38 manu: With this proposal, you have the option to not use @context and be purely registry-driven 09:25:39 q? 09:25:44 Justin_R: what do you mean by "use @context" 09:25:57 q+ to understand what is the governance of the registry, who manages, maintains and executes the rules to reject registrations 09:26:17 burn: There is a JSON format and a JSON-LD format. The specification for the JSON-LD format has to provide context inforation 09:26:38 q+ 09:26:54 q+ 09:27:07 burn: If you do JSON-only there is no @context, there is nothing that looks like JSON-LD 09:27:28 burn: If you want something to the registry, if you want to add a field, you also have to add context information, just like the original specification has to add context information 09:27:46 burn: This means everything has a context, but no requirements are imposed on JSON-only 09:28:10 manu: We thought through the details, we're quite certain this can work. There may be details, but in general the shape looks okay. 09:28:13 ack tplooker 09:28:18 q 09:28:21 q+ 09:28:25 q+ 09:28:30 tplooker: Does this apply to extensions of the core? 09:28:42 manu: Applies to all extensions (properties; not DID methods) 09:28:50 ken has joined #did 09:29:10 tplooker: In JOSE, people can extend but not formally register. JSON developers can just add what they want and not register it. 09:29:17 q+ to ask about a poss req for a test suite 09:29:22 tplooker: Would that not be allowed in the DID document? 09:30:10 manu: I think we should make that decision later. It's important. 09:30:33 manu: One path: This is for all extensions. Other path: Be more loose about it. Either way, we can figure it out later 09:30:40 ack Justin_R 09:30:40 Justin_R, you wanted to comment on the assumptions this proposal makes (and make it clear) 09:31:00 ack selfissued 09:31:31 selfissued: I wanted to ask: 1. Does it matter if the abstract model is "graphical" or "textual"? 09:31:56 burn: It means there will ALSO be graphical representation, in additional to textual abstract model. 09:32:05 manu: This will be helpful to a group of people 09:32:52 selfissued: Main question: Mike Lodder's pull request proposes to add a method name to the top level. Does this break the JSON-LD model? 09:32:56 ack Oskar 09:32:56 Oskar, you wanted to understand what is the governance of the registry, who manages, maintains and executes the rules to reject registrations 09:32:57