<McCool> https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-10-joint-wot-did

scribe+

<ivan> scribejs, set McCool Michael McCool

Greatings to WoT WG

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.)