Re: Special Topic Call, DID WG

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
>>
>>
>>