Re: JSON-only impls of DID core?

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.