- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 29 Oct 2020 08:37:04 -0400
- To: public-did-wg@w3.org
On 10/5/20 9:51 AM, Brent Zundel wrote: > We are holding an additional call on *Thursday, October 8, 2020 at 12 PM > ET.* Oof, regrets. I just realized that a number of us have a mandatory DHS SVIP call at the same exact time, which is really unfortunate. All of the Editors save for one won't be able to make the meeting. I expect none of us caught this because the event wasn't in our calendar at the regular time because of the shift due to W3C TPAC last week. :( In an attempt to try to summarize what we discussed on the Editors call and to provide some structure for the meeting: * It is now clear that the last real Face-to-Face meeting, where we decided to create the DID Spec Registries, led to a number of miscommunications on the purpose of the registry. * One of these miscommunications was a presumed goal by some that the registry would be used in the lossless conversion of representations to other representations. Namely, that it is possible to re-create @context from the registry. We have new information, now that the registry has been created, that this is mathematically impossible under certain conditions, which means that the registry is not capable of doing what some of us had originally intended it to do. * There is also a miscommunication over what a "property" is in the data model. Namely, whether or not it includes "processing directives". Some think Abstract Data Model properties are solely about the DID Subject. Others think that Abstract Data Model properties are anything that is expressed in the DID Document (both registered and unknown/unregistered properties). Thus the discussion today should probably revolve around these items: 1. Come to consensus on the revised purpose of the registry now that it can be proven that it can't do what some in the group wanted it to do (e.g., it is mathematically impossible to use it to construct certain properties like @context). 2. Come to consensus on whether properties are solely about the DID Subject, or if they can be about other things (e.g., the proof property). 3. Come to consensus on whether preserve-by-default applies to all properties in the abstract data model. 4. Come to consensus on whether implementers are allowed to "clean up" the abstract data model before an application uses it to "perform further processing higher up the stack". Here are some proposals to help get feedback from the group: PROPOSAL: The DID Spec Registries MUST contain a section on Representations to enable future representations to be registered in an extensible manner. The DID Core specification MUST specify how this extensibility mechanism works as well as the requirements on representation specifications. PROPOSAL: The DID Spec Registries MAY be used by DID Methods and Representations to inject or modify properties in the Abstract Data Model, even though this might not always be possible (e.g., it is not safe to generate and inject @context). PROPOSAL: All properties in the Abstract Data Model MUST be preserved if the property name and property value are types that the Abstract Data Model supports. PROPOSAL: The Abstract Data Model MAY be modified by software implementations after the consumption process to sanitize or otherwise protect implementations from properties that could lead to privacy or security failures. If we can get a +1 to some variation of the proposals above, we would have a concrete solution that could be applied to the specification. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. blog: Veres One Decentralized Identifier Blockchain Launches https://tinyurl.com/veres-one-launches
Received on Thursday, 29 October 2020 12:37:22 UTC