Re: Side project: JSON-LD checker

On Mon, 17 Aug 2020 at 15:09, Guillaume <gjgd+transmute@protonmail.com>
wrote:

> Hi, thanks for trying it out!
>
> It is a JSON-LD checker, nothing specific to DIDs. We just happened to use
> "didDocument" as an example of a property that's missing from the context
> of the default JSON-LD object
>

Got it, awesome!

A comment in passing regarding the default example, which might be helpful

First of all, why do we use LD at all.  A lot of devs I come across are
familiar with JSON but dont understand the benefits of the -LD part

Well there's a few.  But one of the main ones is that it has a well defined
"merge" function for data.  If you mash together triples/quads they merge
in a well defined and consistent way.

This enables you to have consistent experiences with data, and pull
together data from many different sources to create a web of data

There are some limitations and overhead for achieving this, which is the
trade off

The way it merges data is on having consistent subjects as URIs.  So all
the attributes and values of a single subject get mashed together to become
one thing.  It doesnt matter where in the file that data comes from.

So, looking at this example, with the didDocument we have:

  "id": "did:example:123",
  "type": [
    "CachedDIDDocument"
  ],
  "name": "Farming Sensor DID Document",
  "description": "An IoT device in the middle of a corn field.",
  "tags": [
    "professional"
  ],
  "correlation": [
    "4058a72a-9523-11ea-bb37-0242ac130002"
  ],
  "created": "2017-06-18T21:19:10Z",
  "expires": "2026-06-18T21:19:10Z",

All of these items get tied to the id : did:example:123 URI

But then you tie that to a didDocument too:

    "@context": "https://w3id.org/did/v0.11",
    "id": "did:example:123",
    "assertionMethod": [
      "did:example:123#z6MksHh7qHWvybLg5QTPPdG2DgEjjduBDArV9EF9mRiRzMBN"
    ],
    "authentication": [
      "did:example:123#z6MksHh7qHWvybLg5QTPPdG2DgEjjduBDArV9EF9mRiRzMBN"
    ],
    "capabilityDelegation": [
      "did:example:123#z6MksHh7qHWvybLg5QTPPdG2DgEjjduBDArV9EF9mRiRzMBN"
    ],
    "capabilityInvocation": [
      "did:example:123#z6MksHh7qHWvybLg5QTPPdG2DgEjjduBDArV9EF9mRiRzMBN"
    ],
    "keyAgreement": [
      {
        "id":
"did:example:123#zC5iai1sL93gQxn8LKh1i42fTbpfar65dVx4NYznYfG3Y5",
        "type": "X25519KeyAgreementKey2019",
        "controller": "did:example:123",
        "publicKeyBase58": "6DrzegWwfw8Xg5MsHX95sVnJaPmtXP214B5X9hkG9oRs"
      }
    ],
    "publicKey": [
      {
        "id":
"did:example:123#z6MksHh7qHWvybLg5QTPPdG2DgEjjduBDArV9EF9mRiRzMBN",
        "type": "Ed25519VerificationKey2018",
        "controller": "did:example:123",
        "publicKeyBase58": "DqS5F3GVe3rCxucgi4JBNagjv4dKoHc8TDLDw9kR58Pz"
      }

Now while these two things look like nested objects, from the POV of JSON.
From the POV of LD, or perhaps even the value proposition of LD, they get
merged into one thing.

So those key value pairs might have gone in the parent (or head) property

Then you have

did:example:123 didDocument did:example:123

Meaning the cached document and the did are the same thing, which is
probably not what was desired in terms of structure

I do love the idea of linking a document to a did via didDocument, though

This enables you to put meta data at the document level, and then user data
and crytpographic data at the did level, and link the two together

In HTML/HTTP terminology this is like having the HEAD of the document
(and/or headers) containing meta data and the BODY of the document
containing the content

In block chain terminology this is like having block chain headers and
blocks

If you got this far, thanks for reading.  Love the validator tool, hope
this gives some food for thought in how valid data is structured.


>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, August 17, 2020 3:04 PM, Melvin Carvalho <
> melvincarvalho@gmail.com> wrote:
>
> Looks great!
>
> When I tried to check the default doc I got:
>
> MISSING_PROPERTIES_IN_CONTEXT
> ["didDocument"]
>
> Is it a JSON-LD checker or a DID checker too?
>
> On Mon, 17 Aug 2020 at 14:56, Guillaume <guillaume@transmute.industries>
> wrote:
>
>> Hello,
>>
>> At Transmute we found that as we update our JSON-LD credentials,
>> sometimes we don't update the corresponding context and some properties end
>> up being undocumented, making the credential not signable (because invalid
>> JSON-LD)
>>
>> Therefore we created a tool to check credentials (and other JSON-LD
>> objects) automatically:
>> - https://github.com/gjgd/jsonld-checker
>> - https://www.jsonld-checker.com
>>
>> JSON-LD checker is a JS SDK and a web app to check JSON-LD objects, with
>> the following features:
>> - Paste a JSON and check if it's valid JSON-LD and that all the
>> properties are documented in the context
>> - Paste the url pointing to a file and check that all JSON objects in the
>> files are valid
>> - (Experimental) Paste the URL of a github repo and check that all JSON
>> objects in all files of the repo are valid
>> - Shareable URLs
>>
>> Thought we'd share with the community, feedback welcome!
>>
>> Guillaume from Transmute
>>
>
>