Add TAG security and privacy questionnaire #111
Conversation
explainer.md
Outdated
| > 11. Do features in this specification allow an origin some measure of control over | ||
| > a user agent's native UI? | ||
|
|
||
| Not control, no. User agents may add additional affordances for user transparency and control. |
There was a problem hiding this comment.
Are you discounting the underlying Operating System as part of the User Agent?
This API does allow an origin some measure of control over the OS's UI layer, right (e.g. by opening a bottom sheet with a credential selector?)?
There was a problem hiding this comment.
Agree with @samuelgoto ... further, what fields are requested can have significant influence and could potentially be abused (e.g., an RP asking for 100 things in different ways)
explainer.md
Outdated
| > 12. What temporary identifiers do the features in this specification create or | ||
| > expose to the web? | ||
|
|
||
| None |
There was a problem hiding this comment.
It exposes much worse than temporary identifiers, right? It exposes some permanent ones, like social security numbers and driver's licenses numbers, right?
There was a problem hiding this comment.
I think the exposure of those non-temporary a/k/a permanent identifiers is discussed in the answers to other questions. This question asks specifically about temporary identifiers, and I do not think it makes sense to change its direction.
There was a problem hiding this comment.
Yep that was my reading too. That said, like for other questions, I think we should acknowledge that wallets might create temporary identifiers. I've added a sentence with mdoc MSOs as a possible example (given concern over mdoc selective disclosures being potentially linkable through MSO re-use).
explainer.md
Outdated
| > 01. What information does this feature expose, | ||
| > and for what purposes? | ||
|
|
||
| The Digital Credential API exposes a one-time user-mediated communication channel from websites, to digital wallet applications, and back to websites with end-to-end encryption of the response. It is designed to be a better option than established lower-level communication channels like custom schemes, QR codes, and server-to-server network communication. How exactly this channel is used is up to the wallet applications and host operating system, but we are designing it to be suitable for conveying presentations of digital credentials such as claims in mobile driver’s licenses. |
There was a problem hiding this comment.
Although it's good to talk about the "communication channel" through which the API works, this doesn't exactly answer what information the feature exposes.
In the first sentence, I was expecting to read something like "high-value privacy sensitive digital credentials, such as digital driver's licenses... it does this through a one-time user-mediated communication channel from websites..."
Generally, we should try other the answers specific to the questions being asked. We probably don't need to give justification for the decisions taken (i.e., why it's a better option than custom schemes, QR codes, etc), as we've covered those in other documents (which we should probably link to).
There was a problem hiding this comment.
Agreed with the first part and updated.
I'm not sure I agree about only answering directly. We keep getting people presuming that we are seeking to enable exposure of this information (and arguing against the legitimacy of the use case), when in fact all we're doing is trying to replace existing exposure with safer mechanisms. So I'm just trying to head off the immediate criticisms I know we'll get. But perhaps I've overdone it?
explainer.md
Outdated
|
|
||
| > 04. How do the features in your specification deal with sensitive information? | ||
|
|
||
| Today, online identity verification (e.g., for KYC) is usually done by submitting photos of government identity documents (for example, uploading photos containing the PII via the web’s `<input type=file>` mechanism. Due to the privacy and security limits of this approach, credential issuers and verifiers are working to move to the use of wallet applications which can selectively disclose cryptographically-attested properties. Today, those approaches rely on generic web→app communication paths like custom schemes and server-to-server communication. |
There was a problem hiding this comment.
Generally: I'm worried that this is again tryin to justify why this is a good idea, rather than answering the question being asked. If possible, let's stick strictly to addressing the question not in relation to how it's better than existing approaches. Or, at least, let's de-emphasize the old methods.
There was a problem hiding this comment.
Agreed we should focus first on answering the question directly, I tweaked it for that. But I also think we need to put the answer in context of the larger shifts that our outside our control, right? Otherwise it just looks like it's begging for a "nope, that's dangerous" reaction, right?
explainer.md
Outdated
| > 06. Do the features in your specification expose information about the | ||
| > underlying platform to origins? | ||
|
|
||
| Not directly. Wallets may (intentionally or inadvertently) expose some information through this API (such as some indication of which wallet app the user is using). But the primary motivation for these wallets over traditional federated authentication systems is that the wallet can act in the user’s interest to protect their privacy even from the credential issuer. Issuers generally choose which wallets to support their credentials in and can impose privacy requirements on those wallets. Users will often have their choice of multiple wallets and are expected to use reputation for privacy as part of their decision making. |
There was a problem hiding this comment.
This paints a very optimistic picture / best case scenario of wallets doing the right thing.
Although from the outset this says states that wallets "may (intentionally or inadvertently) expose some information through this API", we should probably outline a worst case scenario.
Like, this could speak about the response data being standardized to be structured in a particular way (even if the browser can't directly peek at the encrypted response data).
There was a problem hiding this comment.
Yeah I can emphasize the risk more. I also added a statement referring to discussion in #117.
|
@RByers, can we move this to a separate document? Otherwise the explainer gets very large. |
First draft of responses to the W3C TAG security and privacy questionnaire.
Tweak from @TallTed Co-authored-by: Ted Thibodeau Jr <[email protected]>
Tweaks from @TallTed Co-authored-by: Ted Thibodeau Jr <[email protected]>
Tweaks from @tellted Co-authored-by: Ted Thibodeau Jr <[email protected]>
Tweaks from @tellted Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
Sorry for the long delay. I think I've addressed all the feedback, @marcoscaceres PTAL. |
|
@RByers, sorry for the silly request... can you make folder called "horizontal-reviews/" and drop this in there. I'd like to keep things super organized in the repo. |
Co-authored-by: Marcos Cáceres <[email protected]>
Sure, silly requests are my favourite 😜 |
First draft of responses to the W3C TAG security and privacy questionnaire.
Preview | Diff