<McCool> https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-10-joint-wot-did
scribe+
<ivan> scribejs, set McCool Michael McCool
brent: special topic call on unregistered properties
McCool: We'll be reviewing WoT
and the issue tracker... I will share my screen and
present.
... WoT is looking at enhancing IoT
... we are focusing on interoperability, not vertical
stacks
... we are looking at ways to describe how things operate and
describing them with metadata rather than prescribing how they
should
... we are 2nd round of charter, we released a Thing
description, looking at updated to that and updates to overall
arch.
... we are looking at discovery, related to how to access
metadata.
... we are also looking at use cases, and narrowing scope
... Thing Description is metadata about an IoT device, using
JSON-LD 1.1
... it includes information about network interactions, it
supports protocol bindings, beyond HTTP
... it also supports schemas, such as JSON Schemas... but its
also mapped to other types such as XML and CBOR.
... we are also looking at semantic annotation, looking an
defining ontologies
... in 2.0 we are looking at things that might overlap with
DID... including JSON-LD Proofs, signing.
... we would like to include the ability to sign the
documents.
... there are various security issues related to
discovery.
... arch, we are looking at lifecycle and interop profiles and
discovery
... once I have a TD, how can i use it
... discovery is 2 phase approach: introductions and detailed
exploration.
... the idea is that you must auth before you can get
metadata
... first contact protocol starts with a URL
... we look at retrieving a TD directly from a device or via a
directory service
... we are looking at DIDs as one of several first contact
protocol options
... we would resolve a DID and follow a link to a device or a
directory service
... because a DID Document has types, we have ways of telling
the difference between a directory or device.
... we can also support URLs
... for DIDs, we want to define 2 types, general type for WoT
and directory
... we have strong sec requirement... we don't want to leak any
data assided form the URL
... we can talk more about discovery, or dive into issues.
<Zakim> jonathan_holt, you wanted to ask when it is appropriate to ask questions to ask about key representations
jonathan_holt: interested in key
representation regarding JWK / CWK
... seems like they settled on vanilla string representations,
thoughts?
McCool: for the directory service
we are looking at HTTP, so its not contrained.
... however p2p is harder, because devices may be
constrained.
... we may recommend that P2P can only be done on HTTP
... we have not gotten all the way there, with http we have
local network, home gateway, etc...
... we are also interested in distributed certs'
... short term, we want to solve HTTP first.
... right now, we are looking at HTTPS, and we are interested
in local HTTPS with other certs... we wish someone would solve
this
... right now, we have to assume HTTPS
jonathan_holt: SDX ???
McCool: we assume HTTPS, and we are not defining how you got it
<jonathan_holt> SXG
McCool: I have a presentation on discovery, there are phases of introduction
<jonathan_holt> https://developers.google.com/web/updates/2018/11/signed-exchanges
McCool: we need to have
exploration after auth
... another constraint is that we want it to be global, and
don't want to be constrained to local network.
... maybe certs could go in a DID Doc?
... final thing, we are also looking at geospatial
queries
... we want to discover based on location
... unfortunately there is not introduction mechanism that
supports location.
... we are adding geo filters to directory
... regarding JSON-LD Proofs, we might add or modify directory
content, and we would want to chain proofing if modifications
happen.
... lets go to the issue tracker
manu: one potential solution is
the use of Verifiable Credentials
... high level, DIDs may not be the best solution, and VCs
might be a better solution for directory services
... it might be simpler than using a DID to use VCs
... there are constrained DID Methods, like did:key that might
do really well in constrained environments
... you could use did:key in constrained environments to do
auth
McCool: if we do use DIDs for
introductions, we would probably take a subset of DID
Methods
... we are interested in hashing / normalization in TDs
manu: lets give an update on the
DID WG
... the core spec is now called "DID Core"
... we focus on authentication and verification of
credentials
... we have an ADM which supports JSON-LD and CBOR, and
JSON
... we have services which might support directories
... we are getting ready to transition to CR soon.
... we won't be adding anything new at this point, we don't see
a need for it.
... you can use type links as the extensibility mechanism for
your use case
McCool: interested in recommended methods for a use case / demo
manu: did:key would be a good
place to start
... there is overlap between WoT, VC and DID regarding
cryptographic proofing and JSON-LD.
... there are options there which should address your use
case
... everything from thing descriptions with proofs, wrapping
TDs in VCs, and publishing TDs in registries.
... a number of foundational components that all these groups
are using, especially RDF dataset normalization
... markus was going to cover disovery
markus: thanks for the intro and
presentation, we've looked at your open issues, and have some
bullet points to discuss
... you seem to have covered most of the focus points in your
intro
... discovery: we understand you are interested in using DIDs
and service endpoints.
... did documents can be extended, so additional service types
can be added.
... did core spec, we have an open topic on discussing a type
property of the did subject
... so the did subject could be a thing, and additional
document could be added.
... but as i understand your metadata concerns, that would not
be a good idea necessarily
McCool: we think DID is good for
introduction from a sec perspective.
... we want to consolidate where security happens, we are
generally cautious about leaking meta data
... we have links and relation types, we are wondering which
kind of relation types might be observable
... if we are linking to the same kind of things, it would be
awesome to define a set of link relation types
<Zakim> JoeAndrieu, you wanted to suggest "type" makes more sense as the service endpoint level, not the DID
joe: I think the use case you are describing, use the type of the service endpoint
McCool: we are interested in
putting the type in the link
... its helpful to know the type before you retrieve
... from a perf perspective
... knowing its a device or directory is not really an
issue
... but we are worried about fingerprinting
... we are worried about randomizing URLs, and fingerprinting
location from metadata
manu: privacy is a big topic of
debate, because dids can refer to people
... the same thing we use to protect people, could be used to
protect WoT
McCool: privacy concerns are
metadata level
... we are concerned that metadata can be used to infer
properties of people
... for example, diabetes devices imply person with
diabetes
markus_sabadello: type of the
subject is one potential extension point, but it makes sense to
also use the service type
... also we usually thing of did resolution as not requiring
authentication
... regarding service types for TDs and Directories
... do you already have some kind of relation type you use?
McCool: we have looked at DNS SD,
and defined some service types for that
... basically WoT Thing and WoT Thing Directory (2 types)
... we don't have subtypes for types of things, because of
concern exposing that.
<Zakim> manu, you wanted to go through the rest of the presentation
markus_sabadello: did resolution
is not defined concretly... only abstractly
... in some cases this can be simple, in the case of did:key
makes not network requests
... all methods have concrete resolution, but some resolution
requires running a blockchain node
<inserted> wot-security issue 166
manu: moving on to security
issues
... issue 166 on WoT regarding integrity protection and proof
on the did document
... we removed it because many methods have ledger specific
protection mechanism
... there are methods like did:web, which may still use the
proof property
McCool: we deferred proofing to
2.0
... we are wondering if we are signing information or syntactic
expression.
manu: have you considered VCs? we
covered this, you should look at it.... did:key is ideal for
constrained environments with no network access.
... its simpler it implement
... CBOR-LD supports semantic compression on did documents, a
did doc can go down to 450 bytes when signed
... in CBOR-LD you can stay in binary, and avoid JSON
parsers.
... its also possible to construct any LD Proof so that you
don't need to normalization
... you can using string templating, to avoid normalization if
you use CBOR and string templating.
... CBOR-LD is brand new and ongoing
McCool: we are interested in that regarding TDs
<ivan> scribejs, set sebastian Sebastian Kaebisch
McCool: TDs can be so long they exceed packet size.
<pam_> Could somebody describe what it means to be "semantically compressed"?
manu: we see folks doing this in
the wild, using hand crafting toolkit
... lets go the Q
<dlongley> pam_, compression based on the meaning of the data instead of compression based on simply its shape/general patterns
Sebastian: interested regarding
CBOR-LD, any documentation?
... we are interested in compressed thing descriptions
<dlongley> pam_, you can get much better compression ratios when you have a "dictionary" (enables semantic compression) of what things mean vs. running generalized compression algorithms that have no understanding of what is being compressed
manu: its brand new and
experimental, there is a presentation deck, and some tests and
examples
... will provide a presentation on JSON-LD compression in
CBOR
... the spec is beyond rough
<dlongley> pam_, and JSON-LD has a "@context" that can be reused as a compression dictionary, enabling CBOR-LD to have semantic compression.
manu: it will probably only be useful in 18 months for so
<manu> Wot-DID slide deck: https://docs.google.com/presentation/d/1NWm50ihWGvPzLeqeqNO3roaDLyH5RFD6n8a4ddca2kY/edit#
<manu> CBOR-LD slide deck: https://docs.google.com/presentation/d/1ksh-gUdjJJwDpdleasvs9aRXEmeRvqhkVWqeitx5ZAE/edit
McCool: we have addressed a lot
of these issues
... type links, need to review extension mechanism
... need to look at signing and VCs
... we think LD Proofs are not ready for adoption
... i'd like to capture some issues we can follow up on
<pam_> Thanks @dlongley that is very helpful
McCool: we need to narrow down a set of methods
manu: see the 65 examples in did spec registries
McCool: we support URL based
introductions
... as long as we can use a DID to get to a URL, we are
good
... did:key seems useful
manu: did:key has downsides, its
so simple, and ideal for local constrained env... what did key
does not have is key rotation, which is ok as long as you have
hardware isolation
... its possible that IoT can use did:key and rely on
organizations to use other did methods to issue TDs or
Directories.
McCool: we are interested in
doing identifier rotation
... we want to support identifier rotation to prevent
tracking
... there are cases where TDs are public, for example smart
city
... you have have parking meter payments
... more public use cases, you may not have personal
information intermixed with devices
jonathan_holt: still wondering
regarding did:key
... interested in discovery via QUIC
McCool: we are interested in
other protocols beyond TCP/HTTP
... quick is of interested, we are just not sure it aligns with
timeline... we still will need an HTTP version
... maybe QUIC is 2.0
jonathan_holt: is QUIC HTTP/3 ?
manu: parts of it are pulled
McCool: obviously if its a standard, its easier for us to use
speaker?
sorry didn't get that question
kaz: asks something regarding group note
McCool: see you on the issue tracker
thanks by all
<kaz> kaz: just fyi, regarding the registries note, Florian from AB will make a presentation during the AC meeting on Oct 20 on the new proposal for the process 2021
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/rragent, draft minutes// Succeeded: i|moving on to|wot-security issue 166 Default Present: rhiaro, JoeAndrieu, justin_r, markus_sabadello, JamesQU, ivan, jonathan_holt, manu, dmitriz, wayne, Alan, Shigeya, Suzuki, Michael_McCool, brent, Eugeniu_Rusu, Kaz_Ashimura, Kunihiko_Toumura, mlagally, Michael_Lagally, Shigeya_Suzuki, Zoltan_Kis, dlongley, Orie, drummond, Alan_Bird, Sebastian_Kaebisch, Cristiano_Aguzzi, chriswinc, identitywoman, burn, dezell, pam, Tomoaki_Mizushima, phila, Erich_Bremer, phila_ WARNING: Replacing previous Present list. (Old list: Alan, Eugeniu_Rusu, JamesQU, JoeAndrieu, Michael_Lagally, Michael_McCool, brent, dmitriz, ivan, jonathan_holt, justin_r, manu, markus_sabadello, rhiaro, wayne, Shigeya_Suzuki, Zoltan_Kis, dlongley) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ rhiaro, JoeAndrieu, justin_r, markus_sabadello, JamesQU, ivan, jonathan_holt, manu, dmitriz, wayne, Alan, Michael_McCool, brent, Eugeniu_Rusu, Kaz_Ashimura Present: rhiaro JoeAndrieu justin_r markus_sabadello JamesQU ivan jonathan_holt manu dmitriz wayne Alan Michael_McCool brent Eugeniu_Rusu Kaz_Ashimura Orie drummond Alan_Bird Sebastian_Kaebisch Cristiano_Aguzzi chriswinc identitywoman burn dezell pam Tomoaki_Mizushima phila pam_ Erich_Bremer phila_ Regrets: ivan No ScribeNick specified. Guessing ScribeNick: Orie Inferring Scribes: Orie Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020Oct/0005.html WARNING: Could not parse date. Unknown month name "10": 2020-10-13 Format should be like "Date: 31 Jan 2004" WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]