scribenick: McCool
Dec 3
<kaz> Dec-3 minutes
had a discussion of signing but deferred until McCool could join
<inserted> (no objections and approved)
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"
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)
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
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
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
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]