Regulatory Compliance Support

[markalanrichards]

I had hoped this was already done, but I get the impression from #628 that there hasn't been a clear decision on privacy protections, suggesting the specification hasn't followed a Privacy By Design process or included appropriate risk assessments.

Please can the w3c provide material of a Privacy By Design approach, supported by Privacy Impact Assessments that businesses can then confidently re-use in their own compliance processes, instead of each business have to do their own Privacy By Design and Privacy Impact Assessment considerations for implementing or adopting this spec.

If implementations, perhaps from Google, are already in use then perhaps Google can volunteer the privacy impact assessment and designs they've already completed to be added as drafts to the appendices to the spec and the w3c process can then review them.

Further Context

Like most country regulators, the UK's ICO has some guidance on this which might be a good starting point, but should be checked against other regulatory environments, I'd recommend checking other countries too; I've always heard Germany has stricter rules about privacy and privacy protections for minors may differ in Canada:
https://ico.org.uk/for-organisations/guide-to-data-protection/privacy-by-design/

It would be awesome, to also have compliance tests and test sample data to help with compliance too as lack of tests can now result in fines for businesses that need online payments https://www.theregister.co.uk/2017/08/17/london_council_fined_over_leaky_parking_ticket_app/

Please consideration should also be made for regulated industries, like Medicines/Healthcare, Finance, etc which may have their stricter privacy concerns. Most countries have additional laws, including in the USA, about protecting the privacy of buyers for these products and regulatory help is more likely to be found from the Healthcare and financial regulators: I doubt all industries need to be covered (like radioactive materials), but the common consumer facing ones would be great.

[marcoscaceres]

hasn't followed a Privacy By Design process

This is not the case: the WG did a security and privacy assessment. We just didn't link to it from the spec.

or included appropriate risk assessments.

Maybe we should link to the google doc (or put it in the wiki)?

Please also note, the spec has received wide review, including from those who have the authority to enforce things like PCI-DSS. It's up to the Payment Handler spec(s) to note any regulatory requirements. For instance - Basic Card notes: "Depending on jurisdiction, users of this specification (implementers, merchants, payment processors, etc.) can be subject to PCI DSS or other regulations. Discussion of those considerations are outside the scope of this document."

[markalanrichards]

Great to see there's been an assessment, but it doesn't seem to include the risks regarding payment descriptions (what people buy), so it needs some work.

The security and privacy assessment also has open issues still cited against it.

For shipping details it doesn't consider the use case that the recipient may not be the payer and the payer may not be legally be allowed to share the recipient information (ie: an employer in a trusted position, purchasing an item for an employee or someone buying items for a friend's daughter).

It would appear that the security and privacy assessment needs to be upgraded with consideration for not just PCI-DSS but for wider privacy law.

I would advise that to do this, personas are created (https://www.agilealliance.org/glossary/personas/) based on a matrix considering some at risk use cases (like minors, professions, demographic groups). The personas should explain the context of their risk.

• minor: unable to give consent in some countries, may need delegated consent
• professions: military, journalists, lawyers, doctors, etc may wish to hide information about what they are buying for other people, themselves or where they are.
• demographic groups: if purchasing products for a religious occasion, like a gay wedding is it safe to have data on what was bought and who the recipient is?
• average user: least concerns, but may have less regular privacy concerns like insurance/healthcare/medicinal services, official documents (passports), etc

There should also be an items matrix, perhaps including items that would be sensitive to the personas and also a discovery exercise to establish whether there are any other considerations: court fines/bail bonds, sexual products, etc.

Apply the two matrices in the context of what information is included in the display details, the requests and responses and what is available to third party scripts running in the user agent (service workers?).

Then with some legal help, get the matrices cross-referenced with international privacy laws and hopefully if you care about privacy someone like the ACLU, EFF, ORG, ICO, etc to identify what needs to be protected.

Then you have a requirements list to redefine your security and privacy assessment by and to improve on it until it is compliant. Then you can fix this spec.

[marcoscaceres]

Great to see there's been an assessment, but it doesn't seem to include the risks regarding payment descriptions (what people buy), so it needs some work.

That's #628.

The security and privacy assessment also has open issues still cited against it.

Sure, we intend to continue to improve the spec as we continue along the recommendation track. Specifications are living documents.

For shipping details it doesn't consider the use case that the recipient may not be the payer and the payer may not be legally be allowed to share the recipient information (ie: an employer in a trusted position, purchasing an item for an employee or someone buying items for a friend's daughter).

The PaymentRequest.shippingAddress includes recipient that can be different from the person making the purchase, which is captured via the PaymentResponse.payerName.

It would appear that the security and privacy assessment needs to be upgraded with consideration for not just PCI-DSS but for wider privacy law.

We are not lawyers tho.

I would advise that to do this, personas are created...

These would be useful, but something browser vendors would undertake in-house. Remember, we (browser vendors) compete on privacy and security aspects. Thus, doing something like the above would be overly prescriptive.

Then you have a requirements list to redefine your security and privacy assessment by and to improve on it until it is compliant. Then you can fix this spec.

Yeah, that's going to be an ongoing process.

[ianbjacobs]

@markalanrichards,

Would you be available to chat with me by phone regarding compliance issues? I would also be happy to share with you some of the work that has been done (including chatting with the
EBA, for example). Best to pursue this by email: ij@w3.org.

Ian

[markalanrichards]

@marcoscaceres
The spec is creating the privacy problem by adding the fields, so when you state:

we (browser vendors) compete on privacy and security aspects

does that mean that the motivation here is to make people vulnerable by default, so browser vendors can compete to sell privacy to those who can afford to protect it (ie: not everyone wants to buy or can afford Apple products and thus Safari)?

I can understand browsers competing regarding aspects like disk encryption of any saved data; FIPS 140-2 compliance, secure synchronization between devices of payment methods, etc, there is a very understandable area for how secure and convenient the browser can make it for a user; but why compete on privacy? We had the discussion about budget tracking and as I explained that is very easily enabled by a separate API that hooks into this upon a user voluntarily adding this service in isolation of their payment methods. So privacy doesn't need to be lost by default.

I'm very worried by the above statement and I'm not sure how to read this other than you are direct conflict with the best interests of consumers and also organisations that are legally obliged to protect their consumers. If the motivation here is to allow freedom for the specification to not protect privacy so it can be selling point of browser vendors; then I would guess that people and organisations that need payments with regard to sensitive data should be advise to go nowhere near this api (governments, healthcare/medicine vendors, minors. etc), which would be a sad state: w3c specs should be for all, not just for the least at risk.

@ianbjacobs thanks, I'm a bit busy this week, but will try to email soon.

[lknik]

@markalanrichards I'm sorry but do you expect W3C to commission a full privacy impact assessment? I'm not sure this would be in scope of W3C's work, especially since this is a work-intensive process. IMO sites requiring a PIA would need to do on their own.

I am definitely not convinced that it is W3C who should be responsible for compliance matters of private businesses (though specifying certain key points in considerations are a must). I speak this as someone involved in Privacy by Design and making privacy impact assessments, too (which are not, by the way, simple questionnaires). That said, I am not sure if W3C is following a PbD process (and is not obliged to do so), though privacy reviews are (mostly always) done. Furthermore, in my opinion this is something for a broader discussion (@torgo) and go well beyond a single spec. I actually pointed to similar aspects in 2016 when I looked at (community-driven) Web Bluetooth. There are likely more beyond.

[markalanrichards]

@lknik sorry, but can I turn that on it's head.
Do you expect every business that uses your specification in Europe to have to do a privacy assessment from scratch when looking at your api? Either you can help them out, or they'll have to assess the privacy impact each themselves. All sites will require a privacy impact assessment throughout the EU
https://www.itgovernance.co.uk/blog/gdpr-and-privacy-impact-assessments-why-are-they-required/

In terms of amount of work, it is one large piece of work to allow lots of business to do a small piece of work, or a small piece of work that forces lots of businesses to do a large piece of work.

If this spec fails a privacy impact assessment, then it is illegal to use in various industries and use cases... risking businesses falling foul of breaking the law because they would erroneously believe the spec was okay and worse the human factor of risking privacy.

We've seen the mess of the Referer header and the pain it causes to try to patch on hacks to fix privacy by design flaws, please put the effort in now, because otherwise it'll come back to bite the w3c anyway as people will have their data leaked to organisations that shouldn't have it and businesses will get sued or forced to spend a lot of time refactoring code and complaining to the w3c to patch a fix into the api.

If you want to understand the Referer mess better, have a look at my Youtube feed https://www.youtube.com/channel/UCt0RTPkU-38xn5rUxZsWTig?view_as=subscriber
The NHS (UK public healthcare) has mismanaged the referer and leaked the browsing habits and reset password links to various companies... that's because of referer: don't make this mistake.

123-reg.co.uk, part of the same company as GoDaddy, has made a similar mistake and replied by email to me:

We have investigated what has been presented and can confirm that there is no security threat here. It may look confusing due to the XCRF key which is on page loads from the server, which is used to prevent other security risks such as CSS, however we are assured that no risks exist here.

The internet is currently implemented in a way that is the opposite of privacy by design, please don't make it worse.

This referer mess is a prime example of how important it is, that this spec cares about Privacy.

[lknik]

Do you expect every business that uses your specification in Europe to have to do a privacy assessment from scratch when looking at your api? Either you can help them out, or they'll have to assess the privacy impact each themselves. All sites will require a privacy impact assessment throughout the EU
https://www.itgovernance.co.uk/blog/gdpr-and-privacy-impact-assessments-why-are-they-required/

First of all, Data Protection Impact Assessment will not have to be performed for all sites, and that article is not stating that.
Secondly, when making a PIA/DPIA, it all depends on the setting. You are asking "what", DPIA should say "why" and "how". It's a standard API, and even using your way of reasoning businesses would still be needed to analyse their existing payment solutions. So if they include a new API, it's only a slight change?

In terms of amount of work, it is one large piece of work to allow lots of business to do a small piece of work, or a small piece of work that forces lots of businesses to do a large piece of work.

Again, a lot depends on the context.

If this spec fails a privacy impact assessment, then it is illegal to use in various industries and use cases... risking businesses falling foul of breaking the law because they would erroneously believe the spec was okay and worse the human factor of risking privacy.

Sorry for off-topic, but is it also the case for other APIs? I think so!
Still, I am not convinced this is the right place to look for a full PIA.

[markalanrichards]

First of all, Data Protection Impact Assessment will not have to be performed for all sites, and that article is not stating that.

Privacy impact assessment will have to be done as some form of exercise everywhere user data is handled in Europe, which will likely include most if not all payment situations. http://www.eugdpr.org/key-changes.html - privacy by design is the legal requirement and thus requires some form of assessment in order to design: if you can design without an assessment then I'm not sure I'd trust the design which is why I'm raising this very serious issue. If you haven't assessed, then you multiply the number of assessments you could do 1 (w3c does it properly) by every adopter on either side of the API who will need to do it instead: if you don't.

For businesses involved with payments of a sensitive nature, like but not a complete list:

• court fines
• clinical trial compensation
• medical purchases
• legal service
• official documents
• childcare support
• ...

it is unlikely to be appropriate to create the risk that the payment processor will receive information that the user purchasing has say:

• a fine for indecent conduct
• is on a cancer trial
• bought Methadone for their addiction
• is getting their will written
• bought a Russian passport
• a 17 year old babysitter hired too look after the kids for tomorrow evening at 6pm
• ...

There are all additional details people want to see when choosing and confirming a payment, but it is unlikely they want them in analytics systems, logs or even just received by a service that doesn't need them.

Sorry for off-topic, but is it also the case for other APIs? I think so!

For most of these sensitive payments, I hope Stripe, Paypal, etc, aren't involved with their full api in use and where they are using the api the organisation adopting them is hopefully going through a painful privacy assessment and having to work out how to anonymise the purchase details, whilst still allowing it to reconcile with some view the customer has (previous web page and reference numbers like 1234? I think I'd prefer a web form!).

As the interface to payments, this api will be at the centre of privacy impact assessments across Europe and for companies that wish to do business in Europe. You can either make their lives easy or risk being another nightmare like the referer header spec.

Governments internationally (not just the EU) are reviewing the privacy of the internet and if this spec is going to last the next inroads to protect users from the invasive tracking that's already happening, then it needs to be a step ahead, not behind of where regulation is going: otherwise this spec is going to be the root cause for people losing their data when payment processors get hacked or leak and for the vulnerability that users already have to misuse of web functionality: like Facebook illegally capturing data because it's so easy with how third party cookies and referers work http://www.telegraph.co.uk/technology/2017/09/11/facebook-hit-12m-fine-spain-breaking-privacy-laws/

[lknik]

Privacy impact assessment will have to be done as some form of exercise everywhere user data is handled in Europe, which will likely include most if not all payment situations.

Sometimes yes, sometimes not. The criteria aren't yet finalized and it "all depends".
I didn't see you citing any relevant sources on PIAs or DPIAs requirements in this thread yet.

For most of these sensitive payments, I hope ...

I'm not asking for payments. I asked if you think W3C should make PIAs for all the standardized APIs in general, and perhaps suitable towards any business out there? If yes, why only focusing on payments, if not, why not? There are, after all, many APIs!

[markalanrichards]

This is the new EU regualtion
http://data.consilium.europa.eu/doc/document/ST-5419-2016-INIT/en/pdf

You'll find various references in there to privacy by design and privacy by default. It's worth searching for those words, even if you don't read the whole spec, to get an understanding of what we need to do in the EU.

I don't think the wider policy of the w3c needs to be the topic for this api discussion, but if you want my opinion:

I think the w3c needs to assess that need on a case by case basis where it decides to explicitly decide what user data will be handled by it's apis and sent to other parties.

For example, if the w3c has a spec for a Message Queue; then it would be silly to worry about the privacy impact, it has made no decision about the data included, it has to be for the parties on either side of the queue to work that out.
But, if the w3c decided to replace email protocols tomorrow with a rest based one that is enriched with user profile lookup; then yes it should go through the same process.

It may need to do this retrospectively if it already has other apis, like this payment api, that make explicit decisions about how third parties will gain to the public's personal data.

[lknik]

@markalanrichards I assure you I know GDPR and the upcoming ePrivacy pretty decently. By the way, I'm in the EU.

Ps. fun fact, it does not contain privacy by design, in fact, the word "privacy" is never used inside.

[markalanrichards]

@lknik
This is a better link https://gdpr-info.eu/

Privacy by design and default is common phrasing, but if you want keywords:

• default
• (data protection by) design

The text of GDPR is finalised, Germany has already signed it into law (for 2018) , but I'm pretty sure from my understanding that all EU member states need to have included this into domestic laws before the deadline in May? I'm not a legal expert, I've just got some awareness from my own reading and also from the last project I was on where we had the analysts reviewing our designs and completing privacy impact assessments.

[marcoscaceres]

Closing as there are no actionable items.