<kaz> scribenick: McCool

agenda

Lagally: would like to recap F2F, then look at PRs
... should also review minutes

<kaz> May-14

<kaz> May-28

<kaz> old minutes to be reviewed above

issues and PRs

<kaz> Use Case Issues

F2F recap

shared summary slide yesterday in main call, is archived under wot/PRESENTATIONS

<kaz> summary slides

Lagally: includes a table of prioritization based on the questionairre
... 15 respondents, categorized horz/vert use cases
... as well as some new use case proposals
... in terms of roadmap, want to make a proposal
... we are in July, and have two streams
... WG note, and New use cases
... we do have a draft index.html file for the Note
... in comments inside that are links to the corresponding md files
... for information, domains from original architecture document

<kaz> Draft use cases Note

Lagally: and a placeholder for requirements (in comments); probably should not be here through, if we want to do this in architecture instead
... but since requirements will take a long time, suggest we leave that out (for now at least) and focus on use cases

Kaz: "new use cases" are the ones in the slide?

Lagally: no, I mean the ones where we don't yet have writeups
... we can only include ones that we have writeups for in the current note

McCool: agree we should take the writeups we have and get them into a note

Kaz: may want to improve the names, call it first and second iteration

McCool: do you want to include all the writeups, or those above a certain priority
... I note that all use cases currently all have at least "2" under business critical

Lagally: accessibility is special...

McCool: probably can review after we get the data into note form
... and it may end up being a horizontal item in each use case
... while we *might* still want to make a special-purpose use case

Lagally: highest priority is just to have a starting document

<kaz> kaz: btw, I can ask the Voice Interaction CG guys to review the MMI/Accessibility use cases

McCool: I think we should start by just pulling in the existing content and translating it to HTML

Lagally: do we have a volunteer?

Matsukura: so we just need to translate into HTML format?
... I will volunteer

Lagally: ok, then after we have that we will have things in content, then we can shuffle things around

McCool: the PR that updates the index file should also archive the md files so it is clear they are no longer the masters
... move to a subdirectory

Lagally: (creates a "processed" subdirectory)

<mlagally_> https://github.com/w3c/wot-usecases/tree/master/USE-CASES/processed

Lagally: (based on Cristiano's suggestion, adds an explanation to the README)

PRs

<kaz> PR 27

<inserted> scribenick: kaz

McCool: dug into some standards on geolocation
... including accuracy for geolocation
... this is a clear geolocation thing
... web apis for heading and speed, etc.
... accuracy includes confidence interval, etc.
... there are references including SSN and geolocation api
... 2 kinds of geolocation apis
... 1. W3C Geolocation API: https://www.w3.org/TR/geolocation-API/
... 2. updated proposal as part of the Generic Sensor API: https://w3c.github.io/geolocation-sensor/#geolocationsensor-interface
... also timestamps
... and ISO standards
... this is a good starting point
... possibly 3 separate requirements
... 1. geolocation information itself
... 2. accuracy
... 3. timestamps
... at least one citing point for timestamps as well here

Lagally: let's put those 3 issues for the wot-architecture
... agree timestamps and accuracy are generic issues
... (generates a new issue on accuracy for wot-architecture)

Issue 526 - wot-architecture

Lagally: (then generates another new issue on timestamps)

Issue 527 - wot-architecture

McCool: kind of related issue with timestamps is time series

Lagally: maybe could be merged as time requirements

McCool: yeah

Lagally: very important to have this

McCool: right

Lagally: need to discuss data formats for timestamps

McCool: also time intervals
... feel free to add comments

Cristiano: ok

<inserted> scribenick: McCool

McCool: I did not do much digging into time standards, so please add additional references

<inserted> scribenick: kaz

Lagally: regarding security considerations
... high-resolution timestamps can be used in conjunction with cache manipulation

<inserted> scribenick: McCool

McCool: not reviewed yet by Security TF, but a start
... also, the geolocation review of the web api in particular surfaced some issues that I think we do need to discuss with DAS

<kaz> PR 27 has been merged

<inserted> scribenick: kaz

Lagally: next, PR 28

PR 28

McCool: discussed it during the security call

Cristiano: still a draft

Lagally: will you continue to work on it?

Cristiano: yes
... added a link to RFC8628

> See OAuth 2.0 security considerations in [RFC6749](https://tools.ietf.org/html/rfc6749#section-10). See also [RFC 8628 section 5](https://tools.ietf.org/html/rfc8628#section-5) for `device` flow.

Lagally: people's reviews are welcome

<inserted> scribenick: McCool

McCool: this is still a draft, still more work to do, but making good progress
... would be great to get a draft we can review in the security call on Monday

Cristiano: will do my best

<kaz> PR 25

McCool: so... let Cristiano do a PR for his use case separately, then later on we can create a combined use case

Lagally: noticed a flaw in the template, have no email, no way to contact

McCool: generally can't include emails in github, spam issues
... but researchers will have a web page with a way to contact them, so...