DID WG and WoT WG Joint Telco — Minutes
Date: 2020-10-13
See also the Agenda and the IRC Log
Attendees
Present (DID WG): Amy Guy, Joe Andrieu, Justin Richer, Markus Sabadello, James Qu, Ivan Herman, Jonathan Holt, Manu Sporny, Dmitri Zagidulin, Wayne Chang, Brent Zundel, Eugeniu Rusu, Shigeya Suzuki, Dave Longley, Orie Steele, Drummond Reed, Chris Winczewski, Kaliya Young, Daniel Burnett, David Ezell, Pamela Dingle, Phil Archer, Tim Cappalli
Present (WoT WG): Kunihiko Toumura, Kazuyuki Ashimura, Michael Lagally, Zoltan Kis, Michael McCool, Cristiano Aguzzi, Tomoaki Mizushima, Sebastian Kaebisch, Erich Bremer, Daniel Peintner, Hazel Kuok, Ken Ogiso
Regrets:
Guests: Alan Bird
Chair: Brent Zundel
Scribe(s): Orie Steele
Content:
Michael McCool: https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-10-joint-wot-did
1. Greetings to WoT WG
Brent Zundel: special topic call on unregistered properties
Michael 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 assisted form the URL
… we can talk more about discovery, or dive into issues.
Jonathan Holt: interested in key representation regarding JWK / CWK
… seems like they settled on vanilla string representations, thoughts?
Michael McCool: for the directory service we are looking at HTTP, so its not constrained.
… 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: SXG ???
Jonathan Holt: https://developers.google.com/web/updates/2018/11/signed-exchanges
Michael McCool: we assume HTTPS, and we are not defining how you got it
… I have a presentation on discovery, there are phases of introduction
… 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 Sporny: 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
Michael 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 Sporny: Wot-DID slide deck: https://docs.google.com/presentation/d/1NWm50ihWGvPzLeqeqNO3roaDLyH5RFD6n8a4ddca2kY/edit#
Manu Sporny: CBOR-LD slide deck: https://docs.google.com/presentation/d/1ksh-gUdjJJwDpdleasvs9aRXEmeRvqhkVWqeitx5ZAE/edit
Manu Sporny: 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
Michael McCool: interested in recommended methods for a use case / demo
Manu Sporny: 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 discovery
Markus Sabadello: 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
Michael 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
Joe Andrieu: I think the use case you are describing, use the type of the service endpoint
Michael 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 Sporny: 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
Michael 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?
Michael 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.
Markus Sabadello: did resolution is not defined concretely… 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
Manu Sporny: See wot-security issue 166
Manu Sporny: 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
Michael McCool: we deferred proofing to 2.0
… we are wondering if we are signing information or syntactic expression.
Manu Sporny: 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
Michael McCool: we are interested in that regarding TDs
… TDs can be so long they exceed packet size.
Pamela Dingle: Could somebody describe what it means to be “semantically compressed”?
Manu Sporny: we see folks doing this in the wild, using hand crafting toolkit
… lets go the Q
Dave Longley: pam_, compression based on the meaning of the data instead of compression based on simply its shape/general patterns
Sebastian Kaebisch: interested regarding CBOR-LD, any documentation?
… we are interested in compressed thing descriptions
Dave Longley: 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 Sporny: 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
Dave Longley: pam_, and JSON-LD has a “@context” that can be reused as a compression dictionary, enabling CBOR-LD to have semantic compression.
Pamela Dingle: Thanks @dlongley that is very helpful
Manu Sporny: it will probably only be useful in 18 months for so
Michael 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
… we need to narrow down a set of methods
Manu Sporny: see the 65 examples in did spec registries
Michael 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 Sporny: 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.
Michael 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
Michael 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 Sporny: parts of it are pulled
Michael McCool: obviously if its a standard, its easier for us to use
Kazuyuki Ashimura: 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
Michael McCool: see you on the issue tracker
Orie Steele: thanks by all