Web Payments Workshop - Session 6

Minutes for 2014-03-25

Agenda
http://www.w3.org/2013/10/payments/agenda.html
Topics
  1. Identity, Security, and Privacy
  2. Identity Management - IETF
  3. Commerce Identity - Microsoft
  4. Decentralized Identity - Ripple Labs
  5. Mobile Identity and Payments - Qualcomm
  6. Pushing Back on Centralization - Lyra
  7. The Web Crypto API and Payments - W3C
  8. Balancing Identity, Privacy, and Anonymity - British Computer Society
Chair
Daniel Appelquist
Scribe
Natasha Rooney
Present
Daniel Appelquist, Natasha Rooney, Virginie Galindo, Hannes Tschofenig, Bryan Sullivan, Ori Eisen, Jörg Heuer, Adrian Citu, Manu Sporny, Mountie Lee, Timothy Ng, Wendy Seltzer, Stefan Thomas, Ernesto Jimenez, Charles McCathie Nevile, Giridhar Mandyam, Erik Anderson, Gregory Estrade, Harry Halpin, Louise Bennett, Joseph Potvin, and 82 others for a total of 103+ people
Natasha Rooney is scribing.
Note: These are minutes for an official W3C Workshop event that have been cleaned up and reformatted by the Web Payments Community Group. The Web Payments Community Group and the W3C are two different organizations, and it is the W3C that managed this event. These minutes may be handed over to the W3C to become the official minutes for the event, but that has not happened yet (and may not happen at all). Readers should understand that there is a difference between officially sanctioned W3C work, and the work done by the Web Payments Community Group (which is not officially sanctioned by W3C's membership).

Topic: Identity, Security, and Privacy

Virginie Galindo: There have been many sessions which have mentioned security, identity, and privacy.
... our panelists are going to talk about this stuff in more depth.
... Hannes will be talking about IETF's role, Giri about work that Qualcomm has been doing. Tim from microsoft talking about product choices. Greg will share deployment solutions related to security. Stefan from Ripple will talk a bit about decentralized identity. Harry Halpin will be providing input from W3C's perspective.
Virginie Galindo: Hannes is up first.

Topic: Identity Management - IETF

Hannes Tschofenig: I work in the IETF and was asked to talk about identity management
... a few years ago there was a pattern where LinkedIn was asking for user/password of email account
... this created many privacy / security problems
... many companies worked on solving this terrible security practice.
Hannes Tschofenig: Many of us have noted the building block approach and use of these
... the original protocol for this was OAuth (an authorization protocol)
... there are many companies using this today, some are in the room, also many smaller companies using this
Slide [2]
Hannes Tschofenig: This is how we defined identity, could be anything from user/password to a rich set of attributes
... not just auth context, usually much more than that
Hannes Tschofenig: So how does OAuth work? It all starts with the user ('resource owner')
... he stores resources somewhere
... he/she wants to give access to this shared resoucre
... an auth server has control of access to this
... it grants this access
... and this uses tokens, it captures the consent you have given and gives the client access
Hannes Tschofenig: Here is a typicaly diaglogue
Slide [3]
Hannes explains the flow of getting an OAuth token.
Slide [4]
Hannes Tschofenig: So the resource owner is the end user
... and this user wants to buy something on a website, the client will then play the role of a merchant
... the merchant then gets the access to withdraw the money from the users bank account
... this is not an abstract concept. You can find descriptions of what these companies have tried to do
Slide [5]
Hannes Tschofenig: I was told VISA Japan uses this mechanism
Slide [6]
Hannes Tschofenig: Those are proprietary extensions on top of those protocols
... but i think we made a good contribution to lower the password sharing of the old patterns
... and helps users reduce the usage of pws
... but we did notice challenges,
... the industry likes to be an 'identity provider' (Google, Facebook, Twitter, etc.)
... but not many want to be a relying party (websites that use Google, Facebook, Twitter to do login)
Hannes Tschofenig: Some hardware reliance for security for example
... the mechanism we have come up with is a decentralised approach
... even still many companies decided to go with a small number of identity providers
... so it's still hard to find a fully open approach to identity providers
Bryan Sullivan: Regarding high interest to be IdP, relying party = identity consumer; most companies want to be the producer instead, and not dependent upon external companies for their user IDs
Hannes Tschofenig: We also noted some companies who use OAuth also use it because they want to be interoperable with other companies
... this can create lock-in
... we cannot force people with what they do in their business decisions, but it is unfortunate
... e.g. facebook only allow you to login with their system
Slide [7]
Hannes Tschofenig: Whitelisting, there are some business agreements which make it difficult to give everyone full open access
... there is some groups like Open Identity Exchange which work on this
... the education industry is also good here
Hannes Tschofenig: In terms of security, some companies ignore our recommendations
... or shortcut it, and optimise it in another way (which creates security holes)
Hannes Tschofenig: With regards to privacy: consent management helped with privacy
Ori Eisen: Facebook will not allow others to authenticate for them, as they can not control the quality of the process. This is a fundamental issue, that can not be solved with technology.
Hannes Tschofenig: Another problem - the relying party asks for more data they they need.
... they can ask for the purpose of the application
... e.g. angry birds asks for location - no reason Angry Birds needs that information.
... FCC may need to kick in to stop this happening, but we are limited in what we can do here
Bryan Sullivan: Dependence upon reliability of the IdP is one reason for reluctance to be a relying party
Hannes Tschofenig: How much data you have to share depends on so many aspects
Slide [8]
Hannes Tschofenig: Here I have included a link to the OpenID Connect protocol - this may be the way forward for attribute exchange.
Virginie Galindo: 5 Minutes for questions...
Jörg Heuer: Have you considered who owns the identity data or who owns it?
... and who takes responsibility for it?
... the stuff we're talking about here may be too technical, but these issues are real.
Hannes Tschofenig: SIM based auth may be the way you want to do it, or a smart card
... we didn't standardise on this, it can be outsourced
USE CASE: Use OpenID Connect to bootstrap a payments process.
Hannes Tschofenig: Also, how do you separate the identity and the person?
Bryan Sullivan: As noted by Hannes, OAuth can be a basis for payment APIs such as the OMA Payment API: http://technical.openmobilealliance.org/Technical/release_program/docs/PaymentREST/V1_0-20130924-A/OMA-TS-REST_NetAPI_Payment-V1_0-20130924-A.pdf
Hannes Tschofenig: Also te auth server and resource are separate components implemented by different implementers
... this makes a lot of sense.
Adrian Citu: What exactly does a payment protocol that sits on top of this look like?
Hannes Tschofenig: The payment mechanisms on top of identity infrastructure already had the hooks to give the consent in the web and mobile app space
... all they did was create additional data structures
Hannes Tschofenig: It might be a good starting point as what can be done with these mechanisms
... e.g. how you provide access from one payment system to a merchant
Bryan Sullivan: As noted by Hannes, OAuth can be a basis for payment APIs such as the OMA Payment API: http://technical.openmobilealliance.org/Technical/release_program/docs/PaymentREST/V1_0-20130924-A/OMA-TS-REST_NetAPI_Payment-V1_0-20130924-A.pdf
Manu Sporny: We looked at OpenID Connect, it's complex - but that doesn't mean that it isn't a solution. We're working on something a bit simpler and that integrates well with digital receipts and payment requests via the Identity Credentials spec in the Web Payments CG. More on this here: http://manu.sporny.org/2014/credential-based-login/
Manu Sporny: It sounds like we're talking about sending credentials back and forth on the Web. Login is sending an "email credential". Payment is sending a "payment provider and authorization credential". It seems like we're saying a credential solution could work by storing credentials in some kind of cloud based identity
... and then have the ability to send the credentials in a very specific way
... for a payment you show up to a merchant and share your payment provider info
... for login you show up to a website and share your verified email credential/info
... it seems like we're heading to a system which manages all of this
Manu Sporny: Have you seen anyone at IETF talk about the transmission of digitally verifiable credentials?
Manu Sporny: Oh, and requestAutoComplete does the same, shares certain details - OpenID Connect, requestAutoComplete, Identity Credentials - these are all more or less doing the same thing (transmitting verified credentials to a website based on your authorization).
Bryan Sullivan: What Hannes is referring to re OpenID Connect use in payments is I think more specifically the use of OAuth (as a fundamental part of OpenID Connect) as a framework for defining the scope of a payment, as in the OMA Payment API I mentioned before.
Hannes Tschofenig: Well, the access token that we have here between the client and protected resource is the credential
... what some of the industry players are working on are a higher security version of this
... currently uses TLS
... we are working on using a key or async credential
... in order for it to be sucessfully deployed it requires existance of standards that harry et al have been working on at W3C
Hannes Tschofenig: With todays browers this is tough, to store stuff in localstorage
... so we have to work on something which is more secure
... so we are hoping W3C crypto work is getting there
Hannes Tschofenig: We are getting closer to deploying this secure version
Mountie Lee: We have seen OpenID, these kind of mechanisms touching for identity, do we think multiple provider (payment, identity, FX etc) we have this idea of expansion
... will there be a gateway?
Bryan Sullivan: OpenID Connect is also being used in the GSMA Mobile Connect API program http://gsmamobileeconomy.com/gsmamc/ as another example of how secure/trusted identity can be seamlessly integrated into mobile services, based upon OpenID.
Hannes Tschofenig: We didn't look much at multiple sources, but people have explored this
... telecomms people have looked at attribute provider (e.g. street address info as well as subscriber data)
... provider has the ability to verify against this data
... idea was that there will be some sort of broker which would make it available to the user
Manu Sporny: A Proposal for Credential-based Login: http://manu.sporny.org/2014/credential-based-login/
Mountie Lee: With the payment provider we don't exchange info cross site, just with provider only
... so address is given to delivery provider only
... possible?
Hannes Tschofenig: Nothing we have done so far makes that possible.

Topic: Commerce Identity - Microsoft

Virginie Galindo: Let's welcome Tim from Microsoft to the stage
Slide [1]
Timothy Ng: I work on the Commerce team at Microsoft.
Slide [2]
Timothy Ng: Our thoughts around identity... I was born in Hong Kong, some time in Singapore and Canada, I live in the US.
... as a result of living in multiple countries i have many bank accounts
Timothy Ng: I also have many social network accounts
... i tend to separate with who I interact with based on what I'm doing
... I also have an address and I went to school and am recognised against these
... these are all things used to find me
Timothy Ng: So we decided at Microsoft that we didn't want to launch a new commerce identity
... we didn't want you to give more info over
... so you take something that identifies you with a commerce identity
Slide [3]
Timothy Ng: This identity identifies you next to these identities
... whatever you created it links to your financial data
... it relates you to rights, you may have purchases an XBox game
... or whatever,
... you have a right to the game, but you may not have paid for it
... you mum might have bought it for you
Timothy Ng: We also model things against your 'friends'
... this could help you give access to some friends so they can access things you have license for
Timothy Ng: We model both buyers and sellers
... so from a commerece perpective we see what is bought and sold
... we have all the info on your purchase history
... we give a score for this
Timothy Ng: We want these commerce accounts to be stored offline and online
... we want you to get a statement at the end of the month as to what you bought
Timothy Ng: Finally we give you the ability to enter multiple payment options and rules
... there are simple rules (50/50 between two credit cards)
... rules can be complicated
Timothy Ng: The commerce identity is separate from your google/yahoo/hotmail
Timothy Ng: We are trying to find out how users can get a commerce account for those who don't have an online profile
... say if user first goes to a store
... so can we use credit card or passport as in ID?
[Slide 4]
Timothy Ng: There are a lot of identity providers here
... we use the oauth protocol to integrate these
... we use different views
... so if you login with your corporate account you get a different view
Timothy Ng: Modelling trust between commerce accounts: so you don't give credit card to merchant
... also limiting spending limits for family members
Timothy Ng: What we have done is only for microsoft products
... we want to extend this
... this is a opportunity for partnerships
Timothy Ng: We want to bridge physical and digital worlds
... also fraud is an issue
... fraud is very siloed
... there is some interesting things to research here
Slide [5]
USE CASE: Associate fraud information and signals with identities.
Timothy Ng: Security, we want to establish a secure protocol
... we may look at some money transfer scenarios
USE CASE: Don't share any theft-worthy data with merchants.
... we are looking at new flows here
... we would like the same API to work across situations
Timothy Ng: We have some issues with security across banks and providers
... ACH is good but hard, we want to work with this
... I'd like to see more encryption in this whole pipeline
Timothy Ng: We'd like to increase interoperability, discover where in the stack these solutions can help. Questions?
Ori Eisen: You cant easily change the 8583 protocol as millions of legacy systems will need to be changed.
Wseltzer, you wanted to ask what about customers who don't want a *single* commerce identity but multiple personalities? and to discuss strong privacy guarantees, if you do link
Virginie Galindo: Just one question from wendy, then wait till the end of all the speakers
Wendy Seltzer: Thanks for sharing Tim. What privacy considerations could you offer to user who doesn't want a single identity? Or who only wants to make payment but not to anything else
Timothy Ng: Good question. Today we allow user to create commerce account and not link org to that identity, and then you can create another account
... then we wouldn't know the accounts were linked

Topic: Decentralized Identity - Ripple Labs

Virginie Galindo: Next is Stefan from Ripple Labs.
Stefan Thomas: I'd like to talk about identity from decentralised networks point of view.
... and how distributed networks can help the issues speakers have bought up
USE CASE: Place identity in a decentralized network
Stefan Thomas: Authentication (identifier could be name, or anything), attestation (a claim of fact)
... we're providing better solutions for trust.
... as a payments WG we would not presume to be more knowledgable on identiy, but look at some of the unique challenges for identity and payment
... and how these distributed networks can help here
... or be impacted
Slide [4]
Stefan Thomas: You have many identities (work, home, gamer id)
Slide [5]
Stefan Thomas: With your identity you can have claims and orgs requesting claims
Slide [6]
Stefan Thomas: Openid connect is pretty good, agnostic to provider
... cryptographically secure
... offers granularity
... supports discovery
Slide [7]
Stefan Thomas: Why would you care if google are your provider?
... Well, they're large, so they're a target, so you might care that they're under constant attack.
Stefan Thomas: Also there is a lot of lockin for some providers
... it's hard to capture this point, but people do think there should be a different way
Slide [8]
Stefan Thomas: OpenID is another option
Stefan Thomas: In ripple, we take a password, we blind it, we take the unblinded value as a key
... have full benefits of identity provider and 2 factor auth
Slide [9]
Stefan Thomas: The other problem is switching providers
... a global identifier could help here
... so Alice can sign things that act on her behalf
... this is independant of any company
Stefan Thomas: So how do i pay Alice?
... we have a mapping from Alice to global pay identifier
... and from there you map to different ways you can pay Alice
... e.g. bank account, or bitcoin wallet
Ori Eisen: How do you know for sure it is Alice who provided the credentials?
Stefan Thomas: This is an early version of what a web payments group could come up with
Slide [10]
USE CASE: Update identity information in a decentralized network (replace payment providers, e-mail attestation, etc.)
Stefan Thomas: So where is this info stored?
... we want claims to not be stored in any particular place.
Stefan Thomas: So we can store these pieces of information in a decentralized location, like Ripple.
Ernesto Jimenez: Relying on reputation could be problematic, creates a barrier to entry.
Charles McCathie Nevile: I agree with ernesto, relying on reputation provides a barrier to entry.

Topic: Mobile Identity and Payments - Qualcomm

Virginie Galindo: Giri Mandyam is our next speaker.
Giridhar Mandyam: Thank-you to the organisers
... i run Web Standards within Qualcomm, with QuIC.
Giridhar Mandyam: We have been doing more in mobile payments given the hardware that has come into play.
Slide [2]
Giridhar Mandyam: Some history, lots of work in premium SMS
... this is still growing!
... not going to die soon
Giridhar Mandyam: Any solution will have to look into how premium sms fits into the open web.
USE CASE: Determine how Premium SMS (operator billing) works with a Web payments solution.
Giridhar Mandyam: Premium SMS is not a great solution, bad rev shares, operators need to eat the bad debt, etc.
Slide [3]
Giridhar Mandyam: Header enrichment, this is actually a very workable and used method
... MSISDN is injected into the header in the operator proxy
... user never knows payment doesn't take place
... but it's not as secure
Manu Sporny: MSISDN (pronounced "misden") is a number uniquely identifying a subscription in a GSM or a UMTS mobile network. Simply put, it is the telephone number to the SIM card in a mobile/cellular phone. This abbreviation has several interpretations, the most common one being "Mobile Subscriber Integrated Services Digital Network-Number". -- Wikipedia
Giridhar Mandyam: Once your outside the network then the operator doesn't know what you're doing
Giridhar Mandyam: Standards could help by setting guidelines.
Slide [4]
Giridhar Mandyam: We are seeing more use of contextual data (geo location etc)
Giridhar Mandyam: We did a lot of research on mobile shopping, particularly germany
... in grocery they scan items and present final barcode and then leave the store
... this was ok, but why can't we use indoor location to tell when they left
... bluetooth access points was not great for indoor location tracking
... the reason was it couldn't keep up with speeds of people moving around
... beacons might help here
Giridhar Mandyam: User should just be able to walk out of the store
... and the purchase should happen.
Giridhar Mandyam: HTML5 has given us some helpful APIs here
... it could help with multifactor auth too.
Wendy Seltzer: Note: We need to think about privacy for contextual information
USE CASE: Protect privacy when making purchases using geolocation technologies.
Giridhar Mandyam: Security is still an issue
... even TLS has security holes
... WebRTC has some issues here with emergency calls, biometric data has issues too
... re trust in browser and TLS, it's not great.
Giridhar Mandyam: EME spec is a bit of a blackbox, so we are getting comfortable with more secure models
Erik Anderson: W3C needs to reference some 3rd party secure hardware... Google and Yubico have been working together on the U2F spec (universal 2 factor)
Erik Anderson: Facebook and Google have been working with Yubico on a hardware solution to remove passwords
... Manu, I have been following this industry for a while. I cant kill the evil anonymous until it is nearly impossible to impersonate someone
... Natasha, Nearly impossible to coordinate a remote attack across multiple devices

Topic: Pushing Back on Centralization - Lyra

Virginie Galindo: Next speaker is Gregory Estrade, from Lyra network
Gregory Estrade: Here we will talk about principles for identity management on the Web.
Slide [2]
Gregory Estrade: We have been concerned with centralised systems and data leaks.
... or surveillance
... there was some expression to centralise the web
... there have been platforms that are more decntralised
Slide [3]
Gregory Estrade: There is a lot of innovation in hardware
... but not just hardware, some innovations are listed here
... secure elements, nfc, biometrics...
... FIDO, identity credentials
... some issues need to be addressed
... ease of use
... related to data aggregation
Gregory Estrade: Currently easy to copy data between devices, this is difficult to trust
... so many devices could produce multiple points of failure
Gregory Estrade: Identity and privacy is different, what you are is what other orgs know about you
... identity is being someone
... trust, trust is a subjective idea
... we talked about cryptography
... you can have trust in something / someone without sharing keys / credentials
Slide [4]
Gregory Estrade: Idea is to build your own web of trust
... you can add your id card, it can be part of your web of trust
... you have to do the choice
... also about education
... facebook have done something for 1/2 years re "Trusted Contacts" - great way of doing Web of Trust for people that don't know anything about it. "Who do you trust with your Facebook login? List 2 people."
Gregory Estrade: Not everyone is web savvy
... anyone could fall into the trap
... you should put people who act as an insurance for you in case someone puts something which is wrong for your service
USE CASE: Figure out a way to couple identities together to allow one identity to retrieve access to another identity if the 2nd identity loses their 2FA device.
USE CASE: Keeping your web of trust in your wallet and only expose it to the outside world when necessary.
Gregory Estrade: There needs to be a balance of things you need to give to the merchant and not.
Slide [5]
Erik Anderson: Manu, most providers allow you to setup multiple 2FA devices for your account in case you loose a device.
Manu Sporny: Yeah, but having multiple devices is a first world privilege. Many people can afford a mobile, and that's it.
Gregory Estrade: Secret sharing: idea is to avoid the point of failure. Shamir's secret is interesting - split private key among 5 people, any 3 of them put together makes the key work.
Virginie Galindo: Shamir's Secret reference : http://point-at-infinity.org/ssss/
... you don't store your credentials in one place but in many places
Manu Sporny: Shamir's secret is considered bad security practice via Bitcoin community - which is why they did multi-sig (in a way that wasn't Shamir's secret). However, the point is that you want to decentralize single points of failure.
Gregory Estrade: Internet of things: could argue the object owns, rather than other way around
... object can become part of your identity
Charles McCathie Nevile: I still rely on a lot of real life social networks for authentication - e.g. in banking...
USE CASE: Secure backup wallet data info to a friends wallet.
Virginie Galindo: We have discussed open id, protocols, security features, better management of identity, now for a W3C perspective.

Topic: The Web Crypto API and Payments - W3C

Harry Halpin: There are a number of problems that we're discussing
... there are a number of things W3C can do, and one of those is the Web Crypto API
Harry Halpin: Up to a few months ago it was very hard to check digital signatures
... this was because those components which were needed for secure applications were not available in the JS runtime
... workshop ran some time ago
Harry Halpin: We can build technical systems that can build secure systems
... and the great success over the past few years is OAuth
... Persona came about a few years ago, but it's dying now.
... but at the same point whilst this was going on the auth stuff was happening
Manu Sporny: I think the Persona team would find the "dying" comment problematic. It's on long-term maintenance and has been handed over to the community. A number of the core concepts are still very sound and should be massaged into future W3C work.
... and now we have the crypto group (lists participants) which are unified on an API
Harry Halpin: So you need to know who has the private key material
... right now the crypto API doesn't allow you to do that
... but now we're working with some new groups: FIDO alliance et al
... so we can get hardware tokens working for the browser
... we're inspecting key storage stuff in browser, new crypto works by some other groups, working with IETF
... working with all these people to develop crypto API and hardware token
Harry Halpin: Pretty sure hardware tokens will have a workshop in September 2014 in Silicon Valley.
... so join the crypto group
... and help us take these implementations to the community so we can discuss them all together
Virginie Galindo: Thanks for the good work in the crypto group, Harry.

Topic: Balancing Identity, Privacy, and Anonymity - British Computer Society

Virginie Galindo: Next is Louise Bennett from the British Computer Society
Louise Bennett: Identity is married to trust
... trust is essential for online payments
... standards for payments on the internet is linked with security, tracability, privacy and anonymity
Louise Bennett: You have to get the right data at the right place at the right time, so you need to be certain for some use that the identifier is linked to what you are concerned with
... since people and orgs are not attached to the internet
... how do you know they are linked on the internet
Louise Bennett: How certain you need to be that it is me or my company that is needing the thing is where we come into risk in the internet
... in the virtual world you may want to know you're dealing with me by many levels
Louise Bennett: In banking transactions the only thing that matter is i opened the account and i am depositing the money
... but there exists legislation
Louise Bennett: Will web paymetns come under jurisdiction?
... I predict p2p payments will start to become regulated
...this will of course have impacts
Louise Bennett: Should you have one or many identities
... most people think you should be allowed to have many identities
... associated with ppl or orgs
... there are terms and conditions assoicated for each
Louise Bennett: Some people think IPv6 is the answer to the issues with identity
... i think that's a non starter
... korean govt mandated that access to korean sites would only be available to those who had government-verified identities, but this was later ruled to be unconstitutional
Louise Bennett: In online commerce you need to be able to prove you've made the transaction
... i like the Alipay escrow model
... in many online / international dealing you need a third party
Erik Anderson: For public record, Anonymity is evil!!! ;)
Louise Bennett: I would say anonymity is not evil, people can hide behind it an do evil things, but it doesn't make anonymity evil
Erik Anderson: :)
Louise Bennett: Privacy is about only providing data to those you want to provide it
Bryan Sullivan: Privacy is also the right to share what you want to share - seems like the same thing as protecting what you want, but it isnt
... advocates of privacy are trying to protect the individual
Charles McCathie Nevile: I wonder if privacy is about providing data, and a sense of what you think it is OK to do with that data
Bryan Sullivan: +1 Chaals - putting people in control of their data is privacy
Louise Bennett: De-anonymisation is much more damaging then anonymity
... seems some people didn't want anonymity, they wanted non-tracability
...some people wanted to hide from the authorities
...they didn't want to hide from friends, just not tracable from the state
Louise Bennett: Many of us achieve this by using the different identities
Manu Sporny: Loving this talk - it really captures the subtleties of privacy/anonymity/security/traceability in a way that can help guide the payments work.
Louise Bennett: Freedom of speech is far more important than privacy
... you must address these issues otherwise standards will have no global validity
USE CASE: Separate the idea of privacy and anonymity when it comes to web payments. Privacy for online actions is important. Anonymity when it comes to financial transactions and moving of money is problematic.
Joseph Potvin: US freedom to - freedom from; EU freedom from - freedom to
Virginie Galindo: We covered the multiple identity issue, user control over their info, protocols and how to make them secure, education
... please ask questions of the speakers during the break.
Charles McCathie Nevile: I'm not sure that we want to draw the lines on what is privacy and anonymity. But I think standards need to support transparency of understanding what will happen to information (money, correspondence, associations, ...)

Created by the Web Payments Community Group. Shared with love under a CC-BY license. Thanks to our contributors.