Re: Special Topic Call, DID WG

The chairs are cancelling the special topic call.
There will be no call held Thursday, October 29, 2020 at Noon ET.
Apologies for the confusion.

We will pick up the topic of production and consumption rules for the ADM
and the representations during our FF2F meetings next week.

On Thu, Oct 29, 2020 at 8:22 AM Brent Zundel <brent.zundel@evernym.com>
wrote:

> When is the SVIP meeting over? Would folks be available after it?
>
>
> On Thu, Oct 29, 2020 at 8:14 AM Dmitri Zagidulin <dzagidulin@gmail.com>
> wrote:
>
>> This doesn't feel right. Those questions and proposals are at the very
>> heart of this Working Group.
>> Holding this meeting when most of the editors, and many of the key people
>> in the conversations are unavailable, seems just disastrous.
>>
>> Is there any way we can reschedule this Special Topic call?
>>
>> On Thu, Oct 29, 2020 at 8:37 AM Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>>> 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
>>>
>>>
>>>