Add TAG security and privacy questionnaire #111
Conversation
First draft of responses to the W3C TAG security and privacy questionnaire.
|
|
||
| A primary use case of the digital credentials API is for selective disclosure of identity properties such as a cryptographic attestation that the user holds a California driver’s license of an adult. The use of selective disclosure, however, is a decision for the verifier website, wallet and credential issuer based on the use case. There are legitimate scenarios, such as creating or recovering an account on a government website, where uniquely identifiable and potentially non-resettable PII is potentially exposed. | ||
|
|
||
| The API is designed to expect the use of response encryption so that this PII is exposed only to the requesting server and not any code running in the web page or browser. It is an [open question](https://github.com/WICG/digital-identities/issues/109) whether this response encryption is something we can reasonably enforce at this layer or not. |
There was a problem hiding this comment.
whether this response encryption is something we can reasonably enforce at this layer or not.
It doesn't seem to me like it is an open question whether this layer can strictly enforce response encryption: it can't.
There is nothing that the browser layer can do (outside of curated allowlists) to circumvent a malicious (or not) wallet from returning the response in plain text.
There was a problem hiding this comment.
I expanded on this a bit more here: #109 (comment)
There was a problem hiding this comment.
| The API is designed to expect the use of response encryption so that this PII is exposed only to the requesting server and not any code running in the web page or browser. It is an [open question](https://github.com/WICG/digital-identities/issues/109) whether this response encryption is something we can reasonably enforce at this layer or not. | |
| The API is designed to expect the use of response encryption so that this personally identifiable information (PII) is exposed only to the requesting server and not to any code running in the web page or browser. It is an [open question](https://github.com/WICG/digital-identities/issues/109) whether such response encryption is something we can reasonably enforce at this layer or not. |
|
|
||
| > 08. Do features in this specification enable access to device sensors? | ||
|
|
||
| No |
There was a problem hiding this comment.
I'm wondering if this answer would change if we included the cross-device flows, where bluetooth is used to prove proximity?
There was a problem hiding this comment.
Technically it would be a different protocol and different specification.
There was a problem hiding this comment.
Technically it would be a different protocol and different specification.
But if this specification uses an algorithm from another specification that does allow access to device sensors, then transitively it does too.
There was a problem hiding this comment.
Agree with @samuelgoto. It indirectly does. So:
| No | |
| Not directly. See question 10. |
And explanation...
| > 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 Open 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)
| > 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.
| > 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.
I would strike the sentence in here about what issuers will generally do, since I don't think it's true across all issuers or credential types (and perhaps wouldn't really even have a meaningful effect, if credentials are thereafter shared with any RP of choice, e.g., "shared with another wallet acting as an RP").
Issuers can and do certainly make wallet suggestions, but focusing on the user making the ultimate choices here seems better.
| 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. | |
| 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. 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.
As a user, I do not want to have 25 credential issuers where each may require a different wallet. Physical wallets are chosen strictly by their users, and they contain whatever physical credentials the user wants to insert. Digital wallets should have roughly the same characteristics.
There was a problem hiding this comment.
Agreed. Nevermind the potential tracking problem with having each issuer require use of their own app. Such an approach would really just be the two party model again and rely on trust in software instead of credentials and cryptographic proofs, recreating problems that the three party model was designed to mitigate.
explainer.md
Outdated
| Today online identity verification (eg. 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 do selective disclosure of cryptographically attested properties. Today those approaches rely on generic web->app communication paths like custom schemes and server-to-server communication. | ||
|
|
||
| The use of wallets aims to improve on the status quo of uploading images in a number of ways: | ||
| * Enable the use of selective disclosure (eg. for more privacy-friendly age 18+ verification) |
There was a problem hiding this comment.
something about being able to do key binding proof of possession?
| * Enable the use of selective disclosure (eg. for more privacy-friendly age 18+ verification) | |
| * Enable the use of selective disclosure (eg. for more privacy-friendly age 18+ verification) | |
| * Enable the wallet to demonstrate legitimate possession of a credential by proving possession of key material bound to that credential |
There was a problem hiding this comment.
I might have gotten lost in the various updates to the PR but don't think anything for this made it in?
| > 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.
Do we mean "end-to-end encryption" here, or are we just trying to say "secure channel".
IOW, not all secure channels need to use end-to-end encryption and end-to-end encryption isn't required for all use cases (presenting a movie ticket, for example).
There was a problem hiding this comment.
Right, this depends on our debate in #109. Perhaps for now I should remove the mention of encryption here for now?
Tweak from @TallTed Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Tweaks from @TallTed Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Tweaks from @tellted Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Tweaks from @tellted Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
| > 02. Do features in your specification expose the minimum amount of information | ||
| > necessary to implement the intended functionality? | ||
|
|
||
| A primary use case of the digital credentials API is for selective disclosure of identity properties such as a cryptographic attestation that the user holds a California driver’s license of an adult. The use of selective disclosure, however, is a decision for the verifier website, wallet, and credential issuer, based on the use case. There are legitimate scenarios, such as creating or recovering an account on a government website, where uniquely identifiable and potentially non-resettable PII might be exposed. |
There was a problem hiding this comment.
| A primary use case of the digital credentials API is for selective disclosure of identity properties such as a cryptographic attestation that the user holds a California driver’s license of an adult. The use of selective disclosure, however, is a decision for the verifier website, wallet, and credential issuer, based on the use case. There are legitimate scenarios, such as creating or recovering an account on a government website, where uniquely identifiable and potentially non-resettable PII might be exposed. | |
| A primary use case of the digital credentials API is selective disclosure of identity properties, such as a cryptographic attestation that the user holds a California driver’s license for an adult. The use of selective disclosure, however, is a decision for the verifier website, wallet, and credential issuer, based on the use case. There are legitimate scenarios, such as creating or recovering an account on a government website, where uniquely identifiable and potentially non-resettable personally identifiable information (PII) might be exposed. |
|
|
||
| > 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.
| 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. | |
| Today, online identity verification (e.g., for KYC) is usually done by submitting photos of government identity documents (for example, uploading photos containing the personally identifiable information (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-to-app communication paths like custom schemes and server-to-server communication. |
| * Enable end-to-end PII encryption between the wallet application and the relevant verification server | ||
| * Enable request authentication, where a wallet is required to cryptographically verify that the requester has permission to access the credential | ||
|
|
||
| Further, this specification aims to improve over the existing communication channels used by websites to talk to wallet apps by: |
There was a problem hiding this comment.
| Further, this specification aims to improve over the existing communication channels used by websites to talk to wallet apps by: | |
| Further, this specification aims to be an improvement over the existing communication channels websites use to talk to wallet apps by: |
|
|
||
| > 10. Do features in this specification allow an origin to access other devices? | ||
|
|
||
| Not yet, but we expect to expand the API to enable cross-device presentation flows using the same mechanism used by passkeys ([FIDO CTAP](https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html). |
There was a problem hiding this comment.
| Not yet, but we expect to expand the API to enable cross-device presentation flows using the same mechanism used by passkeys ([FIDO CTAP](https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html). | |
| Not yet, but we expect to expand the API to enable cross-device presentation flows using the same mechanism used by passkeys ([FIDO CTAP](https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html)). |
| > 14. How do the features in this specification work in the context of a browser’s | ||
| > Private Browsing or Incognito mode? | ||
|
|
||
| Like other browser authentication (eg. WebAuthn) and identification (eg. autofill) features, the feature is available to users to use in private browsing. Regardless of whether private browsing is in use, the feature is designed to not communicate information without the user’s explicit permission each and every time it's invoked. There are legitimate use cases for this API in private browsing such as privacy-preserving age verification. |
There was a problem hiding this comment.
| Like other browser authentication (eg. WebAuthn) and identification (eg. autofill) features, the feature is available to users to use in private browsing. Regardless of whether private browsing is in use, the feature is designed to not communicate information without the user’s explicit permission each and every time it's invoked. There are legitimate use cases for this API in private browsing such as privacy-preserving age verification. | |
| Like other browser authentication (e.g., WebAuthn) and identification (e.g., autofill) features, the feature is available to users to use in private browsing. Regardless of whether private browsing is in use, the feature is designed to not communicate information without the user’s explicit permission each and every time it's invoked. There are legitimate use cases for this API in private browsing such as privacy-preserving age verification. |
|
|
||
| > 19. What should this questionnaire have asked? | ||
|
|
||
| What are the security and privacy implications of not shipping this feature? How does this feature fit into the larger privacy risk landscape. We believe the feature will lead to a reduced risk relative to the status quo, but this is very subjective and hard to demonstrate difinitively. |
There was a problem hiding this comment.
| What are the security and privacy implications of not shipping this feature? How does this feature fit into the larger privacy risk landscape. We believe the feature will lead to a reduced risk relative to the status quo, but this is very subjective and hard to demonstrate difinitively. | |
| What are the security and privacy implications of not shipping this feature? How does this feature fit into the larger privacy risk landscape? We believe the feature will lead to a reduced risk relative to the status quo, but this is very subjective and hard to demonstrate definitively. |
| > 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).
| > 02. Do features in your specification expose the minimum amount of information | ||
| > necessary to implement the intended functionality? | ||
|
|
||
| A primary use case of the digital credentials API is for selective disclosure of identity properties such as a cryptographic attestation that the user holds a California driver’s license of an adult. The use of selective disclosure, however, is a decision for the verifier website, wallet, and credential issuer, based on the use case. There are legitimate scenarios, such as creating or recovering an account on a government website, where uniquely identifiable and potentially non-resettable PII might be exposed. |
There was a problem hiding this comment.
A reader might wonder why when we talk about "use of selective disclosure" but exclude mention of the end user. IMO, it's important to mention the role of the user there.
Nit: expand the acronym PII.
There was a problem hiding this comment.
Might as well be explicit about the nit...
| A primary use case of the digital credentials API is for selective disclosure of identity properties such as a cryptographic attestation that the user holds a California driver’s license of an adult. The use of selective disclosure, however, is a decision for the verifier website, wallet, and credential issuer, based on the use case. There are legitimate scenarios, such as creating or recovering an account on a government website, where uniquely identifiable and potentially non-resettable PII might be exposed. | |
| A primary use case of the digital credentials API is for selective disclosure of identity properties such as a cryptographic attestation that the user holds a California driver’s license of an adult. The use of selective disclosure, however, is a decision for the verifier website, wallet, and credential issuer, based on the use case. There are legitimate scenarios, such as creating or recovering an account on a government website, where uniquely identifiable and potentially non-resettable personally identifiable information (PII) might be exposed. |
| > personally-identifiable information (PII), or information derived from | ||
| > either? | ||
|
|
||
| Yes, the API is designed to help facilitate communication of PII from secure wallet applications to verifier web servers. |
There was a problem hiding this comment.
| Yes, the API is designed to help facilitate communication of PII from secure wallet applications to verifier web servers. | |
| Yes. The API is designed to help facilitate communication of PII from wallet applications to verifier web servers, through a relying party (a web application). |
There was a problem hiding this comment.
| Yes, the API is designed to help facilitate communication of PII from secure wallet applications to verifier web servers. | |
| Yes. The API is designed to help facilitate communication of personally identifiable information (PII) from secure wallet applications to verifier web servers, through a relying party (a web application). |
|
|
||
| > 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.
| 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. | |
| Today, online identity verification (e.g., for know your customer (KYC)) is usually done by submitting photos of government identity documents. This is commonly done by users uploading photos containing the PII using the web’s `<input type=file>` or similar mechanisms. Due to the privacy, security, and usability limits of this approach, credential issuers and verifiers are working to move to the use of wallet applications that can selectively disclose cryptographically-attested properties. Today, those approaches rely on generic browser → native application communication paths, such as custom URL schemes and/or server-to-server communication. |
There was a problem hiding this comment.
| 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. | |
| Today, online identity verification (e.g., for know your customer (KYC)) is usually done by submitting photos of government identity documents. This is commonly done by users uploading photos containing the personally identifiable information (PII) using the web’s `<input type=file>` or similar mechanisms. Due to the privacy, security, and usability limits of this approach, credential issuers and verifiers are working to move to the use of wallet applications that can selectively disclose cryptographically-attested properties. Today, those approaches rely on generic browser-to-native-application communication paths, such as custom URL schemes and/or server-to-server communication. |
|
|
||
| > 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.
| > 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).
| > 09. Do features in this specification enable new script execution/loading | ||
| > mechanisms? | ||
|
|
||
| No |
There was a problem hiding this comment.
| No | |
| No. |
|
|
||
| The use of wallets aims to improve on the status quo of uploading images in a number of ways: | ||
| * Enable selective disclosure (e.g., for more privacy-friendly age≥18 verification) | ||
| * Enable end-to-end PII encryption between the wallet application and the relevant verification server |
There was a problem hiding this comment.
| * Enable end-to-end PII encryption between the wallet application and the relevant verification server | |
| * Enable end-to-end personally identifiable information (PII) encryption between the wallet application and the relevant verification server |
|
|
||
| Further, this specification aims to improve over the existing communication channels used by websites to talk to wallet apps by: | ||
| * Enabling browsers and operating systems to provide meaningful credential selection and permission screens to users, prior to wallet applications becoming aware of the presentation request | ||
| * Securely communicating the origin of the requesting site to the wallet application, so that it can implement its own MITM protection with support of WebPKI |
There was a problem hiding this comment.
| * Securely communicating the origin of the requesting site to the wallet application, so that it can implement its own MITM protection with support of WebPKI | |
| * Securely communicating the origin of the requesting site to the wallet application, so that it can implement its own MITM (man-in-the-middle) protection with support of WebPKI (Web Public Key Infrastructure) |
First draft of responses to the W3C TAG security and privacy questionnaire.