The practicality of JSON-LD

3 views
Skip to first unread message

Josh Bressers

unread,
Aug 8, 2021, 9:21:06 PMAug 8
to u...@groups.cloudsecurityalliance.org
Hi all,

I spent several hours this weekend trying to figure out what a comically simple JSON-LD UVI identifier would look like. I didn't get very far.

Right now JSON-LD is heavily dependent on the schema defined by schema.org. There's not much there that overlaps with vulnerability data (or if there is, I'm not finding it).

My knowledge starts to get thin here, but I think this means we have to construct a new set of schema definitions around this data. That's going to be a pretty big lift.

I love the idea of easily linking and enriching data, but this seems like a pretty high bar. Hopefully I'm missing something.

--
    Josh

Ariadne Conill

unread,
Aug 8, 2021, 9:24:07 PMAug 8
to Josh Bressers, u...@groups.cloudsecurityalliance.org
Hi,
I already built a comically basic vocabulary for describing
vulnerabilities in Alpine's database:

https://security.alpinelinux.org/static/context.jsonld

My plan was to replace that with a JSON-LD vocabulary based on the OSV
schema, which is why I wanted to secure their cooperation. I don't mind
adapting the OSV schema as a JSON-LD vocabulary, at any rate, as I have
mostly done it already.

Ariadne

Josh Bressers

unread,
Aug 8, 2021, 9:49:08 PMAug 8
to Ariadne Conill, u...@groups.cloudsecurityalliance.org
On Sun, Aug 8, 2021 at 8:24 PM Ariadne Conill <ari...@dereferenced.org> wrote:

I already built a comically basic vocabulary for describing
vulnerabilities in Alpine's database:

https://security.alpinelinux.org/static/context.jsonld

My plan was to replace that with a JSON-LD vocabulary based on the OSV
schema, which is why I wanted to secure their cooperation.  I don't mind
adapting the OSV schema as a JSON-LD vocabulary, at any rate, as I have
mostly done it already.


OK, yeah, this is helpful, thanks!

--
    Josh

Ariadne Conill

unread,
Aug 8, 2021, 9:58:22 PMAug 8
to Josh Bressers, Ariadne Conill, u...@groups.cloudsecurityalliance.org
Hi,

On Sun, 8 Aug 2021, Josh Bressers wrote:

>
>
Additionally, https://distfiles.dereferenced.org/vulnpub/context.jsonld
was the JSON-LD context I was experimenting with based on OSV for PubSub
of vulnerability data updates using Linked Data Notifications.

It is not up to date with the latest spec, and still needs a few terms
defined, but should give an idea of what a proper context would look like.

Ariadne

Josh Bressers

unread,
Aug 9, 2021, 8:18:36 PMAug 9
to Ariadne Conill, u...@groups.cloudsecurityalliance.org
On Sun, Aug 8, 2021 at 8:58 PM Ariadne Conill <ari...@dereferenced.org> wrote:

Additionally, https://distfiles.dereferenced.org/vulnpub/context.jsonld
was the JSON-LD context I was experimenting with based on OSV for PubSub
of vulnerability data updates using Linked Data Notifications.

It is not up to date with the latest spec, and still needs a few terms
defined, but should give an idea of what a proper context would look like.


Hi Ariadne,

This was very helpful to get me to a point where I can show what I was working on. I took this and started to mangle it. It's very likely I'm misunderstanding a lot of this. Assume stupidity if something doesn't make sense.

That URL goes to the JSON-LD Playground. I used some existing UVI data for a kernel issue.

My changes reflect what I started with the schema references that are discussed in the JSON-LD documentation. I need to think about the namespacing. It seems like overkill at this point, but I also suspect you've thought about this a lot more than me.

What are your thoughts on how to link between groups? For example we could imagine the CSA and Alpine having links to each other, or some sort of central source, or something else I don't understand yet :)

Thanks

--
    Josh

Ariadne Conill

unread,
Aug 9, 2021, 8:36:02 PMAug 9
to Josh Bressers, Ariadne Conill, u...@groups.cloudsecurityalliance.org
Hi,

On Mon, 9 Aug 2021, Josh Bressers wrote:

>
>
> On Sun, Aug 8, 2021 at 8:58 PM Ariadne Conill <ari...@dereferenced.org> wrote:
>
> Additionally, https://distfiles.dereferenced.org/vulnpub/context.jsonld
> was the JSON-LD context I was experimenting with based on OSV for PubSub
> of vulnerability data updates using Linked Data Notifications.
>
> It is not up to date with the latest spec, and still needs a few terms
> defined, but should give an idea of what a proper context would look like.
>
>
> Hi Ariadne,
>
> This was very helpful to get me to a point where I can show what I was working on. I took this and started to mangle it. It's very likely I'm misunderstanding a lot of this. Assume stupidity if
> something doesn't make sense.
>
> https://tinyurl.com/2389s875
> That URL goes to the JSON-LD Playground. I used some existing UVI data for a kernel issue.

Nice! I like that you've mapped things onto schema.org identifiers.
That's actually really awesome -- web crawlers for example automatically
understand those mappings and can do useful things with them.

> My changes reflect what I started with the schema references that are discussed in the JSON-LD documentation. I need to think about the namespacing. It seems like overkill at this point, but I also
> suspect you've thought about this a lot more than me.

It's overkill right now, but when you think about how individual tracking
databases and hubs will enrich the data, with their own extensions, the
value of having everything properly namespaced becomes obvious, hopefully.

> What are your thoughts on how to link between groups? For example we could imagine the CSA and Alpine having links to each other, or some sort of central source, or something else I don't understand
> yet :)

There's a few ways we can do it. One way is to link using the
`references` collection, obviously. But the other really neat thing about
using JSON-LD is that there's an entire push ecosystem called Linked Data
Notifications. This is what we will build from to enable real-time pubsub
between tracking databases, and it's seen realworld deployment as part of
ActivityPub and SOLID.

https://www.w3.org/TR/ldn/

The exact semantics for how this will work... well, we need to figure that
out obviously: we can build a transactional protocol like ActivityPub, or
simply send the latest version of a tracker's copy of an object and always
treat that as an update.

But the good news is, that as you show in your example, JSON-LD (with its
@id property) allows for cross-domain transclusion, so mirroring data is
already possible this way: you just include your local copy of the remote
object inline in the `references` collection or whatever we want to do
there.

Ariadne
Reply all
Reply to author
Forward
0 new messages