Re: JSON-only impls of DID core?

I'm not opposed to SGL, the main concern I have is that `authorizaton` is
not in did core / did spec registries, if `authorization` were implemented
in https://www.npmjs.com/package/accesscontrol I would have the same
concern... and I imagine there would be the same objections to adding it
from others.

However, I don't think that DID Methods that require a particular access
control / permission system are a bad idea... It's very helpful to have
methods that have unique quirks, like did:github being entirely centralized
and requiring you to have a github account :) ... I think did:v1 requires
object capabilities, so in a way it is  similar to the original did:peer,
but relies on a different technology for the approach.... early ethereum
dids relied on smart contracts, and sidetree relies on custom internal data
model + jws... all are alternative solutions to the same problem of: "How
do i know if this update operation is allowed" ... the problems arise when
the data model must be changed to support that "authorization" scheme...
because that causes questions about interoperability and standards...

I sympathize with the need for something that just works at the
permissioning / access control / capabilities layer... we don't really have
any great standard options, and permission / access modeling seems like a
stretch for the WG at this point, which is why I suggest that we trim
did:peer down to the essentials, align it with KERI as best we can... and
rely on SGL / access control at the app layer / behind service endpoints
where we the development team has full control over the stack and data
model :)

OS




On Tue, Jun 30, 2020 at 5:17 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> On Tue, Jun 30, 2020 at 1:41 PM Orie Steele <orie@transmute.industries>
> wrote:
>
>> https://github.com/transmute-industries/did-peer.js
>>
>> ^ could be adapted to support "JSON-Only"... but worth mentioning that
>> `authorization` in the did peer spec, is built on
>> https://github.com/evernym/sgl and that `authorization` is not
>> registered in did core or the did spec registries.
>>
>
> One of the things that we need to do with did:peer as we align it with
> KERI at DIF is remove this dependence on SGL. I am in favor of that, have
> said so, and had that in mind when I proposed that DIF pick it up; I hope
> this turns into a historical fact only. But I would like to be clear about
> how this fact came about. At the time the did:peer method was written,
> there was verbiage in the DID spec about how we would express authorization
> rules in a section called `authorization`. I needed more sophisticated
> authorization than any other DID method I know. Other important methods
> seemed worried about how to approve a ledger transaction or sign a VC; I
> was dealing with multisig + CRDTs with decentralized version control. Now,
> I'd just finished describing how I could solve really gnarly authorization
> for guardianship, delegation, and controllership in VCs with SGL in a
> purely W3C-compatible way (and was presenting about it at IIW), so I
> thought, "why not apply SGL to this problem, too?" There was no further
> guidance to help me in the DID spec, and none of the extension mechanism or
> the verification relationship verbiage that's been worked out in the past 9
> months. So this oddness is the result of me trying to COMPLY with the DID
> spec too early, not the result of me ignoring it. The `authorization` key
> was deleted out from under me in a PR to did core, and the mental model
> adjusted; this has since made it necessary to reframe that work as an
> extension when it wasn't at the time.
>
> SGL is open source/Apache 2 and always has been. And it's tiny--one public
> function, no dependencies, and 200 lines in node.js; a few more lines in
> python. When I became aware that DigitalBazaar was clarifying their
> capabilities and verification relationships vision in CCG circles, I
> immediately brought up SGL as an alternative in a W3C github issue. I was
> rebuffed for several reasons. Some I think were human and flawed, but one I
> DO consider fair (if solvable) -- SGL would introduce an oddness in how we
> align DID doc structure to RDF triples. So I shrugged my shoulders and
> moved on. This is particularly true because SGL only becomes interesting
> with Level 3 peer DID support, and all existing impls were targeting Level
> 2. I may try to explain how to map SGL to JSON-LD at some point, but it
> didn't feel like a good use of my time then.
>
> So my question is: can you say more about why you feel the SGL quirk is
> important to mention? Do you feel that it disqualifies peer DIDs from being
> a serious attempt at interop because they use an extension that's not yet
> registered? I have been treating extensions as not super urgent for the
> time being; I thought the whole point of them was that we could do them
> later, if they acquired gravitas. If I need to reset my timetable, that's
> important to know.
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>