scribenick: McCool

minutes review

Dec 3

<kaz> Dec-3 minutes

had a discussion of signing but deferred until McCool could join

<inserted> (no objections and approved)

issue review

issues, security terminology

Issues and identifier need clear definitions

<kaz> Issue 571 - identity and identifier need clear definitions

RFC4949 noted by Oliver Pfaff

scribenick: kaz

Lagally: we could add this kind of text
... good approach to refer to RFC

scribenick: McCool

Lagally: a little concerned that some text is omitted, etc; do we really want to cut and paste, etc.

McCool: maybe we should just have a reference

Lagally: am ok with that, since RFCs are stable.

McCool: definitions are a little strange

Lagally: but can we have something better?

McCool: suggest we just put a reference to RFC4949 for now.

<kaz> RFC4949

Lagally: think we should let oliver do this..

McCool: will talk to him, but probably won't see a PR until the new year

Lagally: also System

McCool: I'm down for an MR

Kaz: DID also refers to some of these concepts but seems currently uses wikipedia

<kaz> DID WD

McCool: we should coordinate

Kaz: probably eventually will need something more stable

Lagally: what is their timeline?

<kaz> DID WG page

McCool: look into; also, let's note in issue tracker that a ref to DID would be useful
... and possibly also ISO; see existing defn of "Security"

TD fragments

issue #574

<kaz> Issue 574

McCool: there are also usages for this in discovery, where a query can return part of a TD
... I personally prefer partial TD, but let's stick to one term
... we could say "JSON that partially satisfies the TD specification"
... and can be inserted or expanded into a full TD

Lagally: ok (adds suggested defn to issue)

New terminology for Binding

Lagally: issue #575, new terminology from binding document

<kaz> Issue 575

Lagally: three terms: vocabulary, term, and context extension

McCool: it seems we have the "specific" term "domain-specific vocabulary" but not the general term "vocabulary"
... probably we should look at the TD spec and make sure we are not defining things redundantly

<kaz> terminology issues

Lifecycle and ownership

issue 570, ownership

<kaz> Issue 570

McCool: so I guess one issue... should we even care about "ownership"? What we care about is who has rights to do what
... maybe we should talk about "transfer of access rights" rather than "ownership"

Kaz: would agree
... for example, if we live within an apartment building, the "Ownership" should be a bit different from the one for the house owner.

McCool: also note that ownership does not necessarily map into access rights, e.g. landlord/tenants

lifecycles

issue #561, simplify/add lifecycles

<kaz> Issue 561

Lagally: from issue; "why do we have these"

McCool: maybe the issue is we just need some text explaining why we have these; he's not necessarily arguing against them
... maybe we can just ask zoltan which interpretation he meant...

<kaz> RFC7515

<kaz> wot-profile Issue 55

<kaz> wot-profile PR 57

canonical forms

McCool: summarized JWS, JSON-LD, LD-Proofs, etc.

issue 55, need to make some choices... where it goes, verbosity or terseness, dealing with defaults, ...

McCool: relationship to signing

<kaz> JOSE Documents

McCool: regarding encryption of TDs, one option is to use LWE
... with corresponds with using JWS for signing
... we may want to limit it to a particular set of algorithm
... especially ones that have not been compromized, but are also appropriate to small devices
... one idea is to look at what the COSE group recommends; there will be some overlap with JOSE

<kaz> RFC8152 - COSE

scribenick: kaz

Kaz: wondering about the relationship between this "canonical TD" and the "Thing Model"

Lagally: need to work on both

<kaz> wot-profile Issue 58

<kaz> Lagally's comments

[[

* Single element form with square brackets for security is deprecated, but not for any of the other single array ids.

* We have to find a way that allows canonicalisation and works for the 1.1 release of the spec.

]]

[adjourned]