Create Security and Privacy Questionnaire Answers for Ver 1.1 CR Process

[mmccool]

Answers to current security and privacy questionnaire for TD 1.1 CR Process.
Questionnaire source:

• Dated version
• Most recent version

Status:

• First draft. Still needs review and refinement.
• Here is the version we submitted last time: https://github.com/w3c/wot-architecture/blob/main/proposals/security_and_privacy.md
• Originally our plan was to update this to relate only to the TD but as we have been working through the questions we realized a single set of answers is probably better, but in that case it should go under Architecture. Let's complete this here for now and move it to Architecture later.

To do:

• Update intro so it is relevant for all four versions of this we have to write.
• Update background. @mmccool
• Update questions: copy over questions and links for the new set of questions. Keep old questions and answers for now in a separate section. @mmccool
• Copy over old content for questions already answered. Note that the ids of questions still match in some cases and we should check that even if the ids match whether the same question is really meant. @mmccool
• Review existing answers. In some cases the existing answers (for existing questions) may be ok. @j1y3p4rk @Citrullin
• Generate answers for new questions (that are relevant). @j1y3p4rk @mmccool @Citrullin
• Remove old questions and answers. @mmccool
• Review and refine all answers. @j1y3p4rk @mmccool @Citrullin

[Citrullin]

Not sure about point three "Does this specification introduce new state for an origin that persists across browsing sessions?"
Oauth has sessions and you may be able to misuse them.

[Citrullin]

To point 11 "Does this specification allow an origin some measure of control over a user agent’s native UI?"
Even though the specification doesn't effect UIs directly, it may effect them indirectly. The title and description are supposed to be human readable information. They may get displayed in the UI.
You may be able to place a XSS attack or something in these fields. I don't know if we cover this topic already.

[mmccool]

Regarding 2.11:
XSS attacks, yes, title and description may get used in HTML templates, and a clever person might put some HTML markup or even a script in those fields, and then this gets loaded as part of the page and does nefarious and/or annoying things, like popping up a fake tooltip when someone hovers over the text. This is definitely a "consideration" at least, but a "no" for this question, since we are not giving the origin "control". Mitigations: sanitization, etc. (interactions with internationalization, e.g. script direction, if just strip all HTML... sigh).

[mmccool]

There are 18 questions but the last is a catch-all. Note the branch for this PR is IN this repo so it should be possible for you to edit it directly, or make PRs against it. I would suggest that we all answer or propose answers for the questions in which we feel we have expertise, but please note when you are working on a question here so we don't step on each other TOO much. We should ideally finish this questionnaire by next week.

[mmccool]

For example: I am now working on question 18. (I am; it's a catch-all, though, so I am going to make a bulleted list, feel free to suggest items)

[mmccool]

Not sure about point three "Does this specification introduce new state for an origin that persists across browsing sessions?" Oauth has sessions and you may be able to misuse them.

It says "new state". We can probably answer "no" to this one since we don't introduce "new" state, although we could mention that existing mechanisms we depend on (like OAuth) might manage state.

Although... well, Discovery IS all about maintaining a database that definitely persists, so perhaps the answer is "yes" for Discovery (specifically directories) and "no" for TDs (except for things like OAuth). For Architecture it would be "yes", but only for Discovery. The answer SHOULD be "no" for Profiles (I hope).

[mmccool]

Regarding XSS attacks, yes, title and description may get used in HTML templates, and a clever person might put some HTML markup or even a script in those fields, and then this gets loaded as part of the page and does nefarious and/or annoying things, like popping up a fake tooltip when someone hovers over the text. This is definitely a "consideration" at least, and a "yes" for this question. Mitigations: sanitization, etc. (interactions with internationalization, e.g. script direction, if just strip all HTML... sigh).

I added this consideration to my latest PR against the TD Security and Privacy Considerations: PR #1402

Anyway, I think we should answer "no" to this question, but point out that strings provided might get included into HTML via templates but should be sanitized first (like any other external string; standard web security practice, I even have some links in my PR on how to do it).

[mmccool]

2.1

• TD: Includes information about a Thing's network API (for the purpose of interacting with it) including security mechanisms used (for the purpose of developers needing to know what is necessary to interact with a Thing; non-secret information only), and optionally links to related resources and metadata (at the discretion of the provider, on an as-needed basis).
• Profiles: Restrict the information available from TDs: they define a strict subset, with the purpose of improving interoperability.
• Discovery: Two phases, strictly separated: Introduction (first contact) and Exploration (metadata access). Introductions provide locations (URLs) of Exploration services without providing any metadata; Introductions are for the purpose of finding Exploration services only. Exploration services provide TDs as above, but only after an opportunity to check authentication and authorizations.

I'm thinking we can leave Architecture out of the responses and just include answers for each other deliverable. Note that some questions, like this one, are not yes/no.

[mmccool]

2.2

• TDs provide the necessary API information for a developer to interact with a Thing. Some of the information provided is available upon interacting with a Thing (for example, the security mechanism used) but in some use cases for TDs (such as development) this information is necessary in advance of actually interacting with a Thing instance.
• Profiles define a subset of all TDs.
• Discovery provides a set of TDs, and additional metadata for managing TDs, such as time of last update. This additional metadata is necessary to identify stale information.

[mmccool]

2.3
Normally PII will not be directly embedded in WoT metadata but might be inferred from it. Currently WoT specifications do not deal directly with sensor data but with metadata, which might in some cases be used to infer PII (for example, a type of device, such as a health sensor, might be used to infer a medical condition in its owner, although an association between the device and the owner would have to be determined; it is possible that this information might be optionally included in a TD in some applications). To protect against distribution of direct PII and inferred PII, WoT Discovery mechanisms allow for access controls based on known best methods for web services (OAuth, etc). Other security and privacy considerations warn against embedding metadata in public information that is not protected, such as URLs presented during Discovery Introductions.

[mmccool]

2.4
Besides PII, discussed in 2.3, other sensitive information such as security secrets are never to be stored in TDs. Discovery defines a web service to provide TDs and some Things described by TDs may need to manage sensitive data internally and provide a network interface equivalent to a web service. Both cases should manage sensitive information using known best practices for web services, including encrypting data at rest, using secure transport, and enforcing access control.

[mmccool]

So, it seems we have answers for: 1, 2, 3, 4, 5 (was "three", @Citrullin was looking at the old questionnaire), 11

[mmccool]

2.6
Intent of the question is whether the browser's capabilities are exposed to the server. Translated into WoT terminology, this means exposing the Consumer's capabilities to the Thing. Stated as that, the answer is "no". However, the Thing (which will act as an origin, but may be associated with a user) does expose information in the TD to the Consumer. However, the information is limited to that in the TD, as described above.

[mmccool]

OK, I have filled in answers to 2.1-2.11. In some cases I had to go beyond what we discussed above so please review. In many cases the definitions of "origin" and "platform" were very confusing (or just inappropriate, even if it would have been convenient in some cases to consider them naively) so I had to reword the question to get at the "intent" given that client/server roles can be reversed in WoT easily.

I am going to try to hammer down today and at least get drafts in for 2.12-2.17.

[mmccool]

Some thoughts on the rest of the questions:
2.12 Temporary identifiers. I personally WANTED directories to use local temporary identifiers for this reason, and to avoid collisions (using client-specified ids in a RESTful API is not good practice). However, instead the ids from Things are used, because this is how RDF works apparently, and these are much harder to rotate. It can at least be done when Things are sold, but this still allows tracking, etc. Just going to have to justify it (there are reasons for having relatively stable identifiers, and RDF/SPARQL is kind of forcing us to do this).
2.13 First and third party. I think this may be an N/A but I'm not totally sure. Third-party resources are things like ads on a page, content in a mashup, etc. I think maybe I can interpret it as other resources linked from a TD.
2.14 Incognito mode. N/A. I think.
2.15 Yes.
2.16 Allow origins to downgrade default security protections? No. TDs say what an origin (WoT Thing) does. It does not provide any opt-out mechanisms.
2.17 Non-fully-active documents. N/A, WoT Consumers do not process HTML, etc. They may, however, consume multiple TDs and connect to all of them simultaneously, but the behaviour is defined by the Consumer, not by any of the origins.
2.18 A good place to discuss locus of control, roles (Consumer/Thing), etc.

[mmccool]

I've completed a first draft of answers to all the questions. Please review. Note that at this point we will probably use one set of answers for all deliverables (the answers point at particular deliverables when appropriate).

At some point I will remove the old answers, or archive them in a different file.

[mmccool]

@mlagally I made a bunch of changes which I hope addressed many (but not all) of your review points. Can you review and mark as resolved the ones where your concerns were addressed? I marked as resolved the ones that were obvious (e.g. typo fixes).

[j1y3p4rk]

This statement might be wrong. Why it should be different? A WoT Thing needs both require credentials no matter which/whom the Thing communicate.

[mmccool]

security TF: would be better to be more specific and talk about tokens and OAuth specifically, as opposed to "credentials", which is confusing.

[mmccool]

Modified text as follows:
A WoT Thing may have credentials to establish its identity (authentication) and allow for the creation of trusted secure communication channels with other trusted and authenticated entities. Additional authorization information may be used in addition to manage access rights to specific entities.
Authorizations for secure M2M communication may also reveal the identity
of the accessor but this may not be desired when the accessing entity is a
person or a device that can be associated with a person. In this case, mechanisms such as tokens and OAuth2 can be used, as with other web services, to avoid directly revealing user identities or requiring devices to associate authorizations directly with users.

[mmccool]

Security TF:

• Couple of small things to fix still
• @mmccool will fix and send out an email to ask for reviews to approve
• Once @j1y3p4rk and @Citrullin approve @mmccool will merge

[mmccool]

• Proposed fixes for two outstanding issues done
• @j1y3p4rk @Citrullin Please review, and approve the changes using the review tools if you agree with them

[mlagally]

We discussed auto-generating UIs on the consumer side, so this text is a bit too narrow.
Perhaps just "under control of the manufacturers"

[mmccool]

Closing without merging, however, not discarding, will put in wot-architecture repo instead.

[sebastiankb]

from today's TD call:

• PR will be closed since there is already a PR provided at the Arch repo which is already merged (also see Answers to Security and Privacy Questionnaire wot-architecture#723)
• in the TAG report the link is also shared there