See also: 29 October minutes and today's IRC log
<m4nu> Nick: Looking at revised agenda - look at registration, other changes towards end of day. Straw poll - who needs to leave before end of day
<m4nu> (Only one person raises their hand - MATT)
<m4nu> Nick: Move some things around at end of day, how we work, give ourselves some time - more flows work maybe, an hour where we can dive into other aspects - give ourselves a bit of space in the agenda, use last hour to try and close off initial plan of attack.
<m4nu> Adrian: I think it's a good outline for the day - a bit concerned about how we'll consume the time dedicated time for flows. I think that work we did yesterday was useful starting point to get people to try to represent flows, but I don't know if having this many people having to collaborate on whiteboard added a lot of value. If we try to do what we did yesterday, not the best use of our time. Flows are going to be very useful for our work. I want to talk about how we work on them moving forward, identify some people that will work on that.
<m4nu> Nick: Matt has already volunteered to do that work. It would be good to leave w/ as many names as possible volunteering at end of day. There was a proposal to split up, would rather not do that, may be hard to get all stuff back together again. We have other folks from W3C - that's just trying to get lessons learned, collective wisdom together.
(Brad Hill, Dan Veditz join the meeting)
<m4nu> Nick: Moving on to security considerations
<m4nu> Zach: If we left here w/ a shared understanding of two proposals on table, look at flows, discover whether or not flows fit into proposals - far away from people understanding proposals on table - everyone is clear on what's proposed. We can apply flows to proposals.
<m4nu> MattSaxon: Echoing what was said previously
<m4nu> Brad: We are here to answer questions and free form discussion - we are not aware of specific proposals - share a few thoughts to start the discussion. You are brave in here - security veterans in security space - web payments has to tackle 3 of the most difficult things our group ends up trying to avoid / shutdown as necessary conditions of making your work successful. Difficulty of doing browser-mediated crypto protocols, difficulty of trusted user interface, and difficulty of cross-origin persistent state and identifiers in a trustworthy manner, those seem central to your usecases. Thinking about that, you have a lot of challenges ahead. On browser-mediated crypto - keep it as small as possible - think about long tail of adoption - very large audience, update of browser cycles was slow. A year ago, browsers were fastest movers - chrome updates every week - hits 99% of users - browsers move fast. Now that I'm at Facebook, I see that's only true for the wealthiest parts of the world. There are hundreds of millions that have old android phones, no appstore, no updates, no space to update. Telling those populations to upgrade is like asking them to buy a car to fix a bug in their control system. We can't rev quickly - emerging world, coming on to web - lots of advantages to OAuth - server-to-server, decentralized - economic conditions lead to natural oligopoligies - but when upgrades happen, migration can take a month. Counterparty has to fix it.
<annbass> Re: Brad's statement that everyone updates their browsers quickly ... this does not happen quickly in big enterprise. Example: Boeing often has to wait several years to update, because A) it's expensive to update ~150,000 machines; B) internal applications are dependent on BrowserX (in violation of internal standards). Also, I -- as an average user -- am notoriously slow to update anything
<m4nu> brad: supporting and negotiating multiple protocols over a number of years is difficult, keep it as simple as possible, avoid upgrades, balance natural tendency to have perfectly decentralized world - maintenance costs are high for decentralized - some costs tend to favor some folks.
<Zakim> m4nu, you wanted to talk about the bottom quartile of net worth in the world and the Bill and Melinda Gates Foundation - they fit Brads conditions for "hard to upgrade"
m4nu: Some of the work this group
is doing could have dramatic impact on developing
economies....payments through mobile phones are a big part of
their lives
... we've been chatting with Bill and Melinda Gates Foundation
also; they have a payments initiative to improve ecosystem
worldwide
... there are a number of tensions which direction to go in.
For example, I know we want to get things in browsers
quickly...but we may want to polyfill or deploy more in the
cloud and make the browser surface minimally
... are there a set of API best practices from the security
community that we could look at?
<m4nu> brad: We don't have a security API best practices document, it would be a great thing to have - but it's a collection of folk wisdom and papers, things presented at conferences, no tidy summary that I can point someone to
<m4nu> rbarnes: We don't have a document to point to - the core of what you were getting at was pretty simple, only enshrine in the browser the things you think are going to be constant for a while - we have many payment systems, don't make the details inherent in the browser. That frustrates attention, I think that's the central security tension.
<rbarnes> m4nu: me :) (richard barnes, mozilla)
<m4nu> Doug: Along the same lines, there was a suggestion of making sure that what we design is polyfillable - but then I heard tension around concern that polyfills expose users to security risks - is polyfilling web payment api a good or terrible idea?
<m4nu> brad: SSL should show a lock - lots of history there - do we show URL bar at all, is it green, something as simple as information - secure connection, wildly controversial approaches - I think it boils down to some heart that you have to depend on in browser - crypto properties, sandboxing, what does browser mediate - keep them as small as possible, model them as properties that you depend on,
<m4nu> what they are and what they do.
bhill2: (Ian notes valuable phrase uttered: "focus on properties you depend on")
<m4nu> brad: Polyfills can help you experiment, a strategy in FIDO - great that API design allowed me to design and play around w/ technology, then you can figure out what should be in the browser - you have an adoption curve
<m4nu> Doug: Are you suggesting polyfills for testing or deployment.
<m4nu> brad: Difficult to answer concretely, it's a tradeoff
<m4nu> pat: balance of trust mechanics are great, thank you for commenting on that. We are suggesting individuals operating web payments, but small businesses are also slow to adopt. At the US Fed, we're looking at B2B payments, they're offline checks, 3 day lag, getting trust mechanics right, getting updates to small businesses, business to business is important as well - we should emphasize business-to-business case. That's where people are losing money. Any thoughts with work going on at W3C - any B2B security aspects happening at W3C vs. consumer side focus that we have now.
<m4nu> brad: No particular thoughts on that - those patterns are less challenging. Small businesses have software, get most use of tech before upgrade, but you have less challenges there than the consumer space. Established body of work OAuth, OpenID Connect, other point-to-point protocols, easier to model w/ incentives. Unintentional interactions are harder w/ consumers.
<m4nu> pat: How do we figure out a way to create incentives for small businesses to update - it's not easy to upgrade them, we need something quick, robust, secure.
<m4nu> brad: Google Checkout in google shopping cart was a great example - get users and merchants onboard as quickly as possible, but you want secure signed shopping cart that's harder to attack, you can build complicated protocol w/ lots of options - makes everything more brittle at low-end. So you build two protocols - unsigned protocol - simple... signed protocol is more complicated - we'll charge
<m4nu> 10 basis to use one and 5 to use the other - we'll share risk differential w/ you for pricing structure.
<m4nu> brad: You can decide as a merchant to do what makes sense to you with the risk profile that makes sense to you. Building multiple protocols is better than building one protocol w/ negotiation and options - different incentives is a more easy system to secure.
<m4nu> dezell: Thank you for coming and speaking to us about this. Difference in security between built-in and polyfill - in my daily work, PCI standards. Requires a lot of human engineering, you have to enforce all of this stuff, etc - but compared to that, relative risk implied by a polyfill is pretty modest, but compared to PCI, they're almost the same. I think we're going to try to be as flexible as possible and careful as possible. Any exploit would be bad for us.
<m4nu> nicktr: So, there are three things you wanted to talk about brad...
<m4nu> brad: One thing we're talking about is same-origin policy, sounds simple, but it's complex. Long history of problems on Web about that - poking holes in same-origin to persist identifiers and state changes can happen is something we like to avoid. We want to hold a hard line to same origin. To the extent that you can do tokenization and tailor individual transactions to each origin, great approach
<m4nu> to follow, we don't have good solutions for this stuff.
<m4nu> brad: Biggest tensions I've seen recently is that we're competing w/ the app platform. We're losing to apps - that narrative - there is a looser security model in apps - that's true, but web has its own strengths - we don't want to compete with every feature of app platforms. In an app world, you have discoverability, you have to find app, you have to install it, update cycle, it has to be approved, sometimes app store protects users, sometimes it keeps competitors out. Web has other strengths, immediate deploy, no permissions necessary to deploy, etc. The first principle of the Web is you can do most anything you want - people interact w/ many different security principals, no sense of reputable vs. disreputable sites.
<m4nu> AdrianHB: Do we have to disregard same origin?
<m4nu> brad: There are design patterns for this - get token from 3rd party, do one off transactions, reveal persistent identifiers - that's how paypal works today. Payment instrument - one off transactions across origins, principles, some are more difficult to work w/ offline. Third party can see everything you're doing, you have to trust them, you don't have to trust someone w/ payment instrument
<m4nu> information. Can you get away with that, maybe.
<m4nu> brad: There are design patterns around this stuff - privacy preserving things.
<m4nu> AdrianHB: Is the same origin policy about privacy? not tracking? Or is same origin about trusting the payment instrument because there is some sort of origin?
<m4nu> brad: it's about the fact that user is interacting w/ different origins - you have to protect user by making sure that ... in an app, everything in the app is created by app... on web, you have stuff coming from all different directions - it's not just about privacy, it's about maintaining integrity, security, privacy, etc. We are trying to ensure that every product on every shelf is not able to get data from you, for example. Build multiple protocols, enable people to choose - don't build one size fits all protocol, if you want bitcoin protocol, build that, then build something else that works w/ centralized provider, don't build a swiss army knife, have a spoon, knife, and a fork.
<m4nu> Ian: If we make it easier to pay, we make it riskier for phishing, an easier to pay world - what are the emerging ways to protect consumers from phishing.
<m4nu> DanVeditz: One of the ways we've worked w/ get user media, you can have iframe, you can turn on camera from iframe - we've tried saying "this site is trying to xyz". So when you create your APIs, make sure users understand who is doing it.
<m4nu> Ian: How about getting greater assurances of who you are dealing with.
<bhill2> http://news.yahoo.com/video/yahoo-trust-unconference-security-ux-161037378.html
<zkoch> technically she’s a PM! yay PMs! :)
<m4nu> brad: That's hard - talk at yahoo trust unconference - permissions systems and how to ask for permission - one of the best things I've seen - what is it like to grant permissions - she has lots of good things to say on topic. On emerging technologies - big data systems, behavioral analysis, knock out spammers, prevent clickjacking, that's what payment providers do - analyze all patterns, payment.
<m4nu> in Sapporo, then payment in Nairobi, that's probably not you. browsers building reputation based systems to grant permissions, maybe browsers keep track of site reputation, we might stop people from using camera on that sites.
<m4nu> brad: Or, if you are a heavy user of a site, allow it to have more storage than others. Thinking about how those kinds of things can be in the toolkit are interesting - how to crowdsource reputation, streamline permissions experience, streamline authentication experience w/ sites you use and trust a lot
m4nu: when it comes to SOP and
browser mediation I think there's a lot of confusion and what
it means for APIs.
... that has resulted in people at least in the web payments
group thinking that there's a big blocker that we can't do
payments
... but browser mediation is fine way to do payments
... where do you think it's ok for the browser to mediate
things like payments?
... there seem to be two areas of concern: (1) privacy
[linkability, trackability] and (2) security (not dealing with
malicious sites
... I think it's useful to discuss SOP in at least those two
ways
... I think payments not in conflict with SOP
... when it comes to identity and traceability, I think that's
more of an issue with payments since merchants want data
... in general I'd like to hear your thoughts .... are there
other areas that the group should be looking at using the SOP
lens to figure out whether or not we are deviating from the
basic SOP model
<m4nu> DanVeditz: I don't worry as much about same origin policy, send API out for review.
<m4nu> rbarnes: There is a degree of review around same origin policy - pool of resources that get handed out to any origin that's within a proper realm, there will be some cross-origin stuff - we need to make sure that there is consent around that.
<rbarnes> there is inherent in what this group wants some new cross-origin stuff
<m4nu> DanVeditz: There are ways for sites to violate same origin policy if they communicate - for a payment processor there will be ways to violate same origin - what are privacy considerations, you can't just fall back on SOP, you have to think through that.
<m4nu> dezell: Part of my difficulty in SOP, it sounds like it's a one size fits all problems approach - five years ago, I built a browser system that was PCI approved - opera had ability to sign javascript, my responsibility to send that out - if I had something complicated, I could throw this out to a PHP site locally, doesn't take much squinting to view it as a Web Worker - that kind of layering
<m4nu> possible in security model - big worry is page w/ JS on it - idea that all JS used comes from that page.
rbarnes: "Labeled origin policy"
<m4nu> rbarnes: SOP is a starting point - there are lots of creative usage on that - cross origin - what we care in this group - make clear identification on what comes from that origin.
<m4nu> DanVeditz: That's what you're building w/ an API - if that does stuff, as long as you define that stuff, it's the trusted UA doing that, it can violate SOP all it wants as much as it makes sense to do so.
<rbarnes> in other words: SOP is a misnomer
<nick_s> maybe they shouldn’t have been using the PANs for that in the first place ;)
<m4nu> nicktr: Yes, merchants want to be able to track people - schemes are tokenizing transactions - that's caused problems all over payments industry, payments industry can't track - so now payments instruments are providing payment account reference - so that's a tracking cookie. We should have PCI DSS requirements coming in here - worry at browser vendors PA DSS - I think we're getting very close to browsers getting into PCI scope. Thank you Brad, would Facebook like to join
<Zakim> jheuer, you wanted to say payment technologies often have their own ways to protect their processes - where is the responsibility of browsers, wallets, etc? Abstractions wrapping
<m4nu> brad: no comment :)
<nick_s> you sure wendy? I’ll just do my best impression of you
<m4nu> jheuer: If we're making payment mechanism - broad approach to security - need to find a way to embrace some of this stuff - we want to be clear about SOP and API and limits.
<Zakim> wseltzer, you wanted to comment on heuristics and non-deterministic systems vs user learning
<m4nu> nick_s: Interesting session, thank you brad - lots of desire here to look at PCI and how it applies here - credit card not tokenized payments are big in some nations, but not in others. We may not want the concern spec w/ that, that seems to be a worry of payment instrument - PCI is very much a function of credit/debit - don't know if right approach is to write spec to specific security model -
<m4nu> we want something secure regardless of instrument.
<nick_s> thanks wendy!
<wseltzer> any time
<m4nu> nick: We're out of time, break for 15 minutes, back at 20 past 10, thanks to webappsec for coming along.
MattS: I'd like to hear from people about the approach to diagramming the flows, who wants to be involved
(Display of yesterday's flow now in UML)
(Display of google proposal with 3DS)
(display of the community group proposal)
MattS: Both proposals support 3DS
flow
... that's my conclusion by working through the diagrams
Diagrams done with PlantUML
scribe: very simple text-based
tool...free...hosted in MS Word
... there are web-based versions as well such as web sequence
diagrams
... there were some subtle changes between tools but only
subtle
AdrianHB: Can we check the text source into github?
<Zakim> ShaneM, you wanted to note that PlantUML generates SVG!
<AdrianHB> +1 for a UML tool that allows us to store our data as text in documents on GitHub
Volunteers:
AdrianHB: I propose that this set
of people work together (E.g., as a task force) but that we
clearly state what the goals are.
... e.g., document real-world flows to test our proposals
against.
MattS: I would like to understand the prioritized list of flows we should be creating
adrianba: I caution against
making something too formal at this point. E.g., not necessary
to create task forces in any formal sense.
... it's fine for us to give a group of volunteers an action to
work together how they want to work together on putting
together a set of flows that they believe capture a significant
set of flows we care about, and bring them back to the WG for
review.
... I was happy to volunteer for this but I think many have
volunteered already and efficiency might go done.
... so I'm happy for them to figure out together how to do
their work.
AdrianHB: I will also talk to Mountie as well
<scribe> ACTION: MattSaxon to lead discussion among volunteers about creating flows and diagrams [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action01]
<Rouslan> My website-based instrument registration thoughts: https://goo.gl/656sby
Rouslan: I am thinking there will
be at least 2 types of payment instruments...some will be bound
to the OS; some will be other web sites like paypal.com
... for the Web sites, once you tell the browser that they are
there, there are 2 ways to register;
... javascript API or manifest
... for the javascript API, paypal.com would call to register
themselves. Data includes URL where
user should navigate when they select the payment
instrument
... second approach is manifest (which resides on
paypal.com)
... manifest format (from w3c) is used to specify things like
desktop shortcut or home screen launcher
rbarnes: what is payment request handler URI?
Rouslan: When merchant calls payment request, the browser would overlay a modal window atop the merchant site ... the page would show the URL and use some API that we define here to do something like call navigator.getPaymentRequest
rbarnes: This URL is effectively a Web page that you would open in this overlay once payment instrument selected and communication would take place through something like a POST message.
Rouslan: POST message or
javascript or series of events (but might be too much
freedom)
... some security folks have suggested we make it as small as
possible
... and when vulnerability is found, sites can upgrade quicker
than browser updates
... you suggested WebRTC style of API where the user agent
provides a pipe between sites
rbarnes: I think that's sort of
what you are proposing here but the js of the payment service
provider is in the page
... it's not clear to me you will have UX
... maybe starting with HTML
... having HTML visible entry point may be overkill...we need
to do some more flows to figure that out.
adrianba: I want to take a step
back a second...the topic was "registration" but I heard
yesterday several scenarios for registration that are not
necessarily this.
... one scenario I heard yesterday was "registration of a
particular payment instrument service"
... I heard another scenario which was "I log into my online
bank site and my bank wants to provision my visa card with that
bank into the wallet that is on my device"
... I heard another scenario which was that some people may not
want to tie the payment API to a browser-provided wallet, they
want to have a cloud-hosted wallet (or some other service that
provides access to payment instrument providers)
... I don't know if there are other scenarios but I feel we
need to enumerate them and as a WG we care about solving for,
and whether there is relative clarity
nicktr: The use cases in the IG
were about "how you pay" and not about "how you provision
methods"
... that's a gap that we should tackle as a WG
AdrianHB: Another scenario is "out of band" unrelated to browsing, e.g., I install an App as a payment instrument
<Laurent> +1 on the OOB registration from an app
rbarnes: there may be an information modeling thing to do here...what is the logical set of information the UA has when someone tries to make a payment
<Zakim> m4nu, you wanted to say that we may not want to parameterize in that way - prefer payment method and options
m4nu: +1 to talking about the
registration scenarios
... But on Rouslan's proposal: why have both an API and a
manifest?
... also, I would like to separate the data formats from the
protocols
... also, the proposal is missing a lot of important
information; would be good to have an extensible javascript
format
<Laurent> +1 to having a JSON rather than parameters in APIs
m4nu: I think what is shown is safe but it presumes that payment instruments will have this set of data and nothing more.
<jheuer> +1 to modeling the instrument in a JSON object format
m4nu: I'd like to define the data
a bit more formally.
... Is this set of APIs same as Zach's?
Zach: I had not gone into that level of detail in the explainer
Ryladog: Whenever we do things
that we are going to be showing over time, we want to make sure
we include accessibility.
... I just want to keep in mind that as we go forward.
Rouslan: Your statement about a native app that might be a provider of instruments.
<padler> We should also consider whether registration should be singular cases only, or if we will be able to handle registration collections of instruments or synchronization of collections across user agents
Rouslan: given that it's native it would be platform specific in how it registers itself with the browser
<AdrianHB> Information modeling for registration data needs to be done - consider the 2 uses for this data. 1) Provide the browser with data to render a selection dialogue 2) Provide the browser with enough data to initialize the payment instrument (URL?)
<zkoch> padler: Care to expound? Not sure I understand fully
Rouslan: I'd like to hear your
thoughts on accessibility
... The short name in this proposal could be used for things
like text-to-speech, or alt text
<padler> so if i have already registered a collection of instruments in, let's say Chrome, being able to as a user to synchronize those instruments to other user agents (devices) that I own... with appropriate security of course.
Janina: I'm chair of the
accessible platforms wg (charter). We're excited about
payments and want to help ensure their accessibility
... also Shane McCarron is going to help work on some
accessibility requirements around payments
... what we did with media is talk about disabilities and the
impact on consuming media
... we are thinking of a similar approach to payments
... impact of different disabilities on requirements
IJ: We are not specifying UI...do you have guidance on API design?
janina: We don't know all the
answers. But for examples, there are topics like
"Timeouts"
... some people need more time.
... we may also need to think about the flow overall and user
interactions in doing payments
... we need to do some of that to expose what the APIs will
need
... I have only one today...I think there will be others.
Ryladog: I think we need to have
some guidelines ... such as around the use of biometrics
... I know that there are more than those two things ; we are
just starting work on guidance for API designers
... there are other things to keep in mind as spec writers such
as ensuring examples in specifications demonstrate
accessibility
nick_s: What are some of the challenges people face today when making payments?
janina: Most locking devices on
mobile have big accessibility issues.
... if you have not enabled NFC you cannot use it.
... that may not be for w3c to solve.
... we had several things like that in media where simply
enumerated things to keep in mind.
... Another ecommerce scenario is something like hearing prices
as I am standing in line.
... in terms of online payments, there are questions like a
trust service where you don't have to re-enter credentials will
be valuable.
... timeouts may be necessary to take into account for some
users
LJWatson: When I gave some
feedback on the IG's use cases, Manu and I exchanged some
emails; one idea that came out of discussion is guidance to
people writing user interfaces when using these APIs.
... in terms of the API itself, Ian asked where does
accessibility fits in...until we know more about the API it's
difficult to be sure...but it occurs to me that there may be
data to exchange in the course of a transaction that may be
important to someone with a disability.
... for example, there may be (as Janina said) a need to
provide timeouts
Janina: if you need a timeout, you almost always need it so you shouldn't have to set it every time.
Rouslan: there was a question
about how can APIs and accessibility work together given that
API happens in the browser...it was always my understanding
that payment would only proceed with user consent.
... so this implies UI and the browser would have to ask
permission regardless of the user's accessibility needs.
Rouslan: so we definitely need to be considering accessibility around consent
<Zakim> m4nu, you wanted to say that it might be interesting to have someone navigate our polyfill prototypes w/ various accessibility tools with the designers sitting beside them. and to
m4nu: Thanks for coming today;
consistent review through the entire spec development process
will be valuable.
... having Katie and Shane in the group will be helpful
... Leonie's review was very helpful (and so we now have
accessibility considerations throughout the use cases
doc)
... in addition to review, it would be good for many of the
people in the room to show people via demos how assistive
technologies work with the protocols that we come up
with.
... so those are two requests: (1) regular review (2)
demonstrate use of assistive technology with prototypes
<Rouslan> +1 to accessibility demos
<Zakim> AdrianHB, you wanted to discuss UI inputs (information modeling for payment instrument) and suggest a stand-alone guidance document to accompany our rec
AdrianHB: Thanks again for
coming. Rouslan covered a point I wanted to make - information
design around "what a payment instrument it." There are two
pieces of information there...assistance to the browser in
rendering the "chooser" UI...ensuring sufficient information to
ensure that the chooser UI is accessible
... also because we are not specifying UI, we may wish to
create a companion Note on accessibility guidance for
implementers of the spec.
<Zakim> ShaneM, you wanted to ask about guidance on embedded payment windows
(IJ: I think we could consider a companion implementer guide but not limited to accessibility)
<AdrianHB> +1 ian - implementer guide (with accessibility section)
ShaneM: Suppose I am on a site and have an interface for choosing to pay
janina: somebody might want a
unique sound that can help me make out when there's a payment
event
... I need to then be able to switch focus
Shane: there are also security issues around permissions
Janina: Is there an event requirement in the API (e.g., to trigger a sound)
<Zakim> jheuer, you wanted to create an environment to ease integration of accessibility easier
jheuer: Options could be a key
element
... if today we only have PIN and that's a hurdle to some
... but there's a device that also supports fingerprint
janina: I named one benefit - an itemized receipt that you can read is a big deal
<Zakim> nicktr, you wanted to talk about invisible payments and confirmation
nicktr: You raised an important
point - an explicit confirmation.
... I think that's spot-on from an accessibility
perspective
... but merchants are seeking to remove explicit interactions
where they can
... e.g., think of Uber...implicit when you order the taxi.
<nick_s> to be clear though, that model’s no different to many other pre-ordering scenarios
nicktr: There are also issues
with cognitive impairments; understanding that an action will
cause a payment to happen
... mandated confirmation would be a barrier to adoption
... by some merchants
janina: there are also usability ideas about "consistent styling of information" when types of events happen such as payments
<Zakim> shepazu, you wanted to talk about a Payments UI Community Group to talk about non-normative (informative) UI guidelines, including accessibility, security, privacy, and so on
shepazu: Although UI is outside
the scope of our charter, I've spoken with other groups where
they want to have a UI component. .....maybe there is an
opportunity for a CG to document UI considerations
... there could be a UI guideline around payments that, if we
could get the payments people involved, could be great.
<AdrianHB> suggestion: implementer guide should recommend that UAs allow a user preference that forces user consent every time a website wishes to call the payment API
<nicktr> manu has the last word
(We should be sure to talk with browser folks about their thoughts on consent UI)
m4nu: Nick asked an interesting
question about examples where accessibility requirements come
into play
... time required is one issue as has been called out
... another topic that is interesting is when a larger industry
push ends up forcing better accessibility
... in the retail space, for example, there's a push to use
mobile devices to do checkout
... that can benefit accessibility..people can use their own
devices to check out
... if we could enable that scenario through our work, then we
might increase accessibility overall
<annbass> I just wondered if there are similar i18n considerations at this point?
m4nu: one area in the API where we can pay attention is to allow rich markup in data that is exchanged in the API that might affect display
<AdrianHB> LJWatson: that's a good suggestion. I think this will manifest as data about the user (such as accessibility reqs) being stored by the browser (wallet) and passed (with user consent) to the payment instrument for consideration.
m4nu: are there other things we can annotate in data objects that are either requirements or that enable accessibility tools to build richer UI
<dezell> Note that if any economic incentives are made available through a non-accessible interface, that is a legal liability for the provider.
<dezell> That is the provider's problem, but we must keep it in mind.
Ryladog: There are other data topics like "don't turn data into images that are not accessible in transit"
<LJWatson> AdrianHB Yes, very much I think.
MattSaxon: there will be some bits of information that will be used in UI....
AdrianHB: We need to ensure that the API must include enough information so that the user agent's rendering can be made accessible.
<jheuer> ...I'd even say that the data format will be decisive in many ways to the interactions possible in the UI
MattSaxon: Can we mark up our data so that it's clearer what is for machines to consume and what is for people to consume?
shepazu: That would help somewhat but might miss some things like timing.
LJWatson: With eBay where you
have auction countdown...you can preset a final amount and let
system do time-sensitive bidding
... In some of these APIs, I wonder whether there are
mechanisms to declare viable authorization mechanisms
... eg., not using a retinal scan.
AdrianHB: opportunity for
browsers to store accessibility requirements and optionally
pass them to the payment instrument with the payment
request
... there are of course privacy issues
<zkoch> I think this is a platform-level thing
<zkoch> Not something for payment specifically
dezell: There are liability
issues [in some jurisdictions for some types of site]
... if site is not accessibility
... like the idea of guidelines for implementers
<AdrianHB> zkoch: you're right. We do need to think about if the payment instrument's user interaction is ever going to be done in a context where the accessibility requirements aren't known...
m4nu: Gates foundation interested
in payments work...
... are projects like financial services for the poor to those
who don't have means to get it.
... is that an accessibility issue?
katie: It is by the US Fed
... study shows majority of unbanked also have large proportion
of disabilities
... mobile can help a lot
IJ: Got other spec guidelines for helping accessibility review?
janina: we have a charter requirement to do something like that
(Cf charter about UI accessibility in implementations)
(Dom Hazael-Massieux (DHM), Martin Thompson, Eric Rescorla (ERK) join the meeting)
DHM: we communicate with third
parties for identity verification
... might be an interesting model for some payments work. WebRTC has P2P
identification for end-to-end encryption (see 9.1 Identity Provider Interaction)
... each peer gets their id validate by a third party identity
provider
... in a traditional client-server world you use certificates
but can't do that in a p2p world
... want to ensure that the person you think you are
communicating with is that person
... the model is that the ID you claim to have is validated by
a third party
(Dom shows a communication graph on the screen)
DHM: Suppose you are on w3c
webrtc service and want to connect with Adrian on Skype.
... w3c javascript will ask for verification of Adrian, and the
verification will be done via JS that was gotten from
skype.com
... will be executing code from two entities
... the JS executes in a separate global context
... it has the properties in terms of security and
isolation
... also has a lot of flexibility in terms of how the ID
provider provides the service
Martin_Thompson: Looks like a
Worker
... browser asks questions like "please generate an identity
assertion"
... or "I have an identity assertion can you validate it and
tell me who this assertion is for"
... ,and the response can be yes or no
... you can hide arbitrarily complex interactions (e.g.,
checking back at the server). Done safely
within a sandbox
UNKNOWN_SPEAKER: you are
operating in your own origin; not running code in your own
origin
... the code you get from your identity provider is from a
well-known URI
... you get it from skype.com
... for example
rbarnes: There is analogy to service workers
AdrianHB: Isolated execution environment with a well-known standard API into that environment from the browser.
Richard; We define that API in IDL
scribe: in most webidl we talk about the provider being the browser...in this case, the browser is the client of the Api and "an application" is the actual provider
DHM: How does it apply to
payments?
... in payments you will likely have identity management...so
this might be useful to you
scribe: more generally it's useful for third party integration
DHM: I thought the model was interesting enough that might inspire you for the payments APIs
<Zakim> m4nu, you wanted to say that Social Web WG might need identities, Web Annotations WG might need identities, Web Payments WG might need identities, so how many specific identity
m4nu: We are talking about
identity and identity integration and a number of payment use
cases require strong identity.
... open question in this group on how to do this
... partly there's a question for the TAG - there are multiple
Working Groups that have started ways to create identities and
they are not aligned.
... that's one question (for the TAG).
... do you think that this group could just reuse the identity
integration mechanism that you've built?
... we do need to verify identities...do you think it could be
fit or extended for payments on the web
Richard; I don't know what identities you intend to create and consume in this content.
scribe: there are a number of
assumptions here that are bound to the context in which this
work operators
... one necessary piece is that the assertion you make is bound
to a "context"
... the way this is constructed, the IDP sandbox doesn't need
to know; the browser is responsible
... the IDP only sees a string that they want someone to attest
to
... the model is simple and might be useful (produce ->
consume) but you might need to tweak it
Laurent: I am interested in understanding the drivers behind the choice to have the IDP verify the credential rather than defining a fully verifiable credential outside the IDP.
Martin: We did a survey of
technologies early in this process and determined there was no
commonality among these things.
... we needed generation and verification of assertions
... whether these technologies did that was uncertain
... our approach of "providing code" enabled the impedance
mismatch
... took away need to agree on algorithms etc.
... boiled down to "please create an assertion" and "is this
assertion valid"
rbarnes: If we want to support a lot of payment systems we will likely want to support something like this
DHM: I think at a high level
people can adapt their systems to these 2 simple
operations...it should also allow innovation due to
flexibility
... if you support these two operations you can interop with
webrtc
Martin: We discussed a proposal
... you can take the same interface to a sandbox and codify in
an HTTP request..that's relatively straightforward
... the information that traverses that interface is relatively
well-defined
jheuer: +1 to that kind of
flexibility
... What did you not find specifically in openID connect or
other solutions?
Martin: Commonality
... You duck a large number of interop issues by doing it this
way
jheuer: So can you imagine a
common credentialing / identity interface to use this context
across different application fields?
... webrtc is not the only one that requires bi-lateral
interaction?
Martin: Yes, I think the pattern
could apply to other domains.
... but we'd need to try a few times rather than forecast
universality of the approach
EKR: Sounds more like FIDO to me
<Zakim> AdrianHB, you wanted to suggest this model may be useful for "hosting" a payment instrument however it doesn't deal with UI
AdrianHB: In a conversation with Richard this came up....part of this was applying this model as the way to get payment instruments
<dom> Identity Provider Interactions in WebRTC API
<dom> Provider Interactions in WebRTC API
Martin: as opposed to
downloading code from an origin, you fetch code that performs
payment instrument operations
... but no UI it seems. In our conversations, the
conclusion was that sandbox would reject things since UI needs
not met
... the least well tested part of the API is sending user to
another site for interactions with user.
AdrianHB: So the standard is how
to fetch execution logic.
... this may be a way to handle payment instruments in cases
where there is no UI
... could have a URI where user interactions are required
... but where not, could specify something like a URI where you
fetch code to execute
Martin: That particular cat can be sliced a number of ways
<Zakim> padler, you wanted to ask about assertions/assumptions that IDP can make about ID consumer execution environments
padler: Are there assertions or
assumptions that Identity providers can make ...e..g., I need
to enforce that both browsers implement something in a
particular way?
... also, as we are looking at browser interactions, there are
some interesting use cases around P2P payments
Martin: A lot of what this
enables in WebRTC is effectively UA-to-UA communications
... one use is to create isolated media...I can send you things
without site involvement (they can't see or change the
media)
... exposing APIs to make information available within that
context is relatively straightforward...you can add payment
specific hooks if you need them
padler: I can imagine there would
be identity providers for certain use cases in the payment
space, where the community is a restricted subset.
... the origin has available all the information it would have
on a regular page
... if you have users logged in you have all the context you
would have...and that can be part of the sandbox when it's
started up
... that information can be put into the sandbox
... that's where the next level of power comes from...you can't
do this with declarative forms
... we thought that was pretty powerful
<Zakim> m4nu, you wanted to ask if you have an example of what this looks like (code / specs / etc.) and to ask if this is specific to WebRTC?
m4nu: One thing is the design pattern; another is the implementation in the WebRTC spec
Martin: It's more loosely coupled than you'd think
m4nu: If it's loosely coupled,
many of the things you do there mirror many of the things we
are doing in credentials CG and also the payment instruments we
are talking about here.
... I noted that other groups are also thinking of doing the
same thing (TAG discussion as I mentioned)
<gjaya> wouldn't naming conventions matter? ie do they have a 'package' independent of webrtc?
<Zakim> AdrianHB, you wanted to suggest this might also be a way for payment instruments to verify request data from the merchant/payee
AdrianHB: The only other thing I
want to point out for consideration is the potential for this
to be a way for the payment instrument to verify data from the
merchant
... if there was a need you could pull down the verification
mechanism from the merchant's web site and the payment request
could be verified against it.
<Laurent> +1 to verifying the merchant
EKR: The question is what are the
invariants from the paying side
... in order to produce a payment, what do you need to know
AdrianHB: The way I see this working is you are on a merchant web site....payment request made ...
ERK: there is "bound" and there is "verified" and that's not the same thing
AdrianHB: Suppose Paypal got data...there's no guarantee that data wasn't changed en route...there's a way to pull down logic and get confirmation such as "verify this really is your merchant ID number"
ERK: Let's take something less
straightforward than Merchant number
... Distinguish that which needs to be supplied to the payment
instrument and ....
rbarnes: the API that the
identity provider sees is different from the API that the web
page sees that is making the call
... the identity provider thinks in terms of signing and
verifying assertions
... the web page thinks in terms of identities.
... the browser's role is to take that identity and present it
to the identity provider
... the group needs to think about what the receiving might
want to see and what the payment instrument would provide
CyrilV: Regarding the payment
constraint, we should have in mind to respect the contractual
links of payment systems
... merchant has a contractual like with his service
provider....and user with his/her service
provider...crosschecking would be difficult and perhaps not
useful
AdrianHB: I propose we consider
this just in terms of verifying data
... it doesn't have to be integral to the payment process
itself
... it's something we can look at as an option ... how we
verify data being passed around
<m4nu> End of day discussion: we should review "things we agree on"
<MattSaxon> I suggest we use it to review hard questions and focus on not solving, but deciding how we will proceed about solving i.e. capture some actions with specific assigned people
(Philippe Le Hégaret joins the meeting)
<m4nu> Testing Howto (in Github)
Philippe: presents testing at
w3c
... testing is complicated
... starting point is "Test the web forward"
... we don't care about the w3c process
... but w3c can make use of the TTWF project
... Fixing the web is a lifetimes work
... The good news is that submitting stuff via TTWF
automatically tests with some browsers. The testing
infrastructure is all there
... the science of browser testing is imperfect
... API tests via testharness.js
(Philippe demonstrates on screen)
Philippe: testharness.js supports
assertions, asynchronous testing
... metadata is minimal
... assessing coverage is problematic. reftest not applicable
(needed for screen display)
... manual tests are sad tests
... describes visibility change example
... Web IDL tests will make you cry because browser
implementations are imperfect
... client-server tests we have two examples: xmlhttprequest
and web sockets
... we don't expect people to use web platform test
server
... if the server is up you can use it
... but the preference is to do a local install
<Zakim> m4nu, you wanted to ask about HTTP APIs - can you test that stuff in TTWF? and to ask if there are WebDriver suites that you can put /somewhere/?
manu: we are going to have 3
types of testing: browser apis, serverside http api, web
driver
... the last is not supported by ttwf
... if we were to write web driver tests, are there
requirements to ensure future compatibility
jgraham: one of our goals is to
allow you to do the testing from one html file
... if you write a test today, it feels like in 6 months time
you should be able to use that
... prompt dialogues aren't supported but you can think about
extending web driver for that sort of thing
... for example we are looking at bluetooth but the pattern
isn't there yet
<Zakim> shepazu, you wanted to ask about autogen tests
doug: do you have a pattern for json-ld?
(manu: whispers it's not needed)
ShaneM: is it providing data factories?
phillipe: no
ShaneM: your not exercising the methods, just checking that they exist
Philippe: correct
dezell: client-server: do you write your own server?
phillipe: no, we have code to do
that
... we don't need to know ip or local name, we have meta-syntax
to let those tests auto-generate
... we have IDNs (?) as well
shaneM: I brought up the environment on a virtual server in 20 minutes. well played.
Philippe: as a WG you need to
convince the Director - one of the ways is to prove you have
the test suites
... results. Stick them in the w3c/test-results repo is one
approach
... we'd ideally like the results directly form the browser
vendors
... There are two kinds of licenses. WG doesn't have to worry.
All sorted.
...Strategies: don't wait until the last minute
... No mods without tests
... find a leader who can understand w3c/web-platform-tests and
get them to guide the group
... there are no w3c dedicated resources
... but the docs are pretty good
... and there is an irc channel: #testing
<Zakim> AdrianHB, you wanted to clarify process
adrianHB: to clarify. the WG will write as we go locally but submit to TTWF repo ?
Philippe: Correct
... Submitting early heads off mistakes
AdrianHB: we are hoping to be iterating on tests and recommendations rapidly
Ian: a long time ago (2005) there
was a QA Framwork Spec guidelines was published
... do the test folks have more up to date guidelines for TTWF
style tests
jgraham: be careful with respec
ShaneM: don't do what RDFA did with regard to algorithms
adrianhb: can you tag things in respec to mark things for testing?
phillipe: there's no tool for that
jgraham: there _are_ tools but there is not usually a mapping between must statements and tests
phillipe: (shows directory
listing of web-platform-tests repo)
... web socket server running inside each server, supports
TLS
ShaneM: is there a driver to run over collection of tests
Philippe: We have a little test
runner
... (shows runner)
... takes a directory as an argument
... only runs js tests
... Better way is to you WPTrunner
... runs on Firefox and chrome. Working on Edge. No
safari
... advantage of the latter is that can run reftests
... and makes it more tolerant of browser crashes
ShaneM: does EARL still exist?
Everyone: nope. move along. nothing to see here.
Philippe: we don't want anyone to run manual tests
<m4nu> NO
(schepers explains the role of test lead. Test wrangling is the principal role)
<Ian> (Shane volunteers to lead the test work)
ShaneM volunteers magnificently
<Ian> Other people who will be interested in writing tests: m4nu
AdrianHB: any volunteers for testing writing.
Manu: we will be writing tests
Schepers: anyone writing product will be writing tests
sub-topic: tooling
<zkoch> +1 to github
<zkoch> Github ALL THE THINGS
nicktr: I suspect that there is consensus on using GitHub as our primary collab tool
<Ian> https://github.com/w3c/webpayments
(chair notes no objections)
nicktr: to clarify; will we use the wiki functions of GitHub
manu: limitations on GitHub to history
ian: there is a commitment to
persist work product and also to use neutral tools
... we don't need to be rigid if everyone can access the
tool
... begs the question, what will we use the mailing list
for
nicktr: GitHub has a notification framework should this be wired to the mailing list
<Zakim> ShaneM, you wanted to talk about the purpose of the mailing list
adrianba: it's possible, is it desirable
shanem: mailing list will be used
for agenda's and other discussion
... it makes sense to be able to archive what goes on in
GitHub
<Ian> (There are also discussions of archiving github repos on w3.org...another topic for another day)
shanem: we could wire event hooks from GitHub to services at W3C so they are persisted
shepazu: there are tools to do
this
... everything is being archived
nicktr: is w3c archiving everything on GitHub
shepazu: there is an automated publishing framework that lets us push drafts from GitHub to the site
<Zakim> m4nu, you wanted to mention github tracker vs. being able to track stuff against spec + mailing list
shepazu: to clarify, we have talked about taking snapshots of the GitHub content but are not doing that now
manu: let's just use GitHub issue tracker as this helps with our responsibility for tracking comments
m4nu: how do issues mentioned in the mailing list get into the issue tracker?
<Ian> ACTION: Shepazu to look into connectivity in both directions between a mailing list and github repo in both directions [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action02]
ian: there appears to be an action to investigate how to do this?
adrianba: Microsoft opinion is we should no longer use mailing lists for technical discussions because using something like GitHub allows the discussion to be threaded, tagged, closed and explicitly re-opened. Mailing lists are open to abuse of the status of an issue
GitHub allows you to subscribe to issues if that's what you want
scribe: Some groups have
configured GitHub to send mails to the mailing list but my
preference would be to use an alternative mailing list if we do
this.
... The mailing list does have value for meta discussion
shepazu: Minutes are not filed but often issues are raised in meetings. Suggestions for addressing this?
adrianba: The practice that is encouraged is that if issues are raised in the call they are filed at the time and referenced
<zkoch> +1
adrianba: same applied on the mailing list
shepazu: does anyone have a problem with using GitHub
<Ian> NickTR: I can't get to github from my corporate account
nicktr: But this isn't an issue for me. Are there others with similar issues?
cyril: not sure
kris: we don't have access but I can work around this
shepazu: I believe it is possible to mail responses back to GitHub
Ryladog: Do we have experience with using GitHub for the WG functions
ian: most WGs are doing this. we have some learnings. the chairs will need to monitor this and ensure we are not missing any of our obligations and learning from other groups.
<Zakim> m4nu, you wanted to ask if we're going to have problems w/ issue engagement w/ people that are not familiar with Github - tends to be a techie audience.
adrianba: there is a rec that was created using GitHub
m4nu: +1000 to using GitHub but I
worry about excluding non-technical or other stakeholders
... we will exclude people but I think we still want to use
GitHub
ian: to clarify the only thing they can't do is make submissions?
<Ian> IJ: I don't want to limit interaction; people who can't use the tools should have other routes including email and we should support their interactions
nicktr: I am prepared to make sure that if there are things we want to share more widely that they are in an easily accessible format and place
MattSaxon: The flows collaborators are all potentially being excluded
nicktr: MattSaxon will look at solving this
Laurent: Can we migrate any prior work to our new repo
shepazu: if they are specs then
they should be at the W3C root repo other stuff
... at the group repo
<kris> just to correct myself: i do have github access (joehoe!)
Cyril: Can we get an email that summarizes this
sub-topic: meeting cadence
nicktr: there is a request that we accommodate our participants in the East
proposal is to run weekly meetings and alternate the time to be morning (UTC) and afternoon (UTC).
<ShaneM> +1 to the alternating schedule
mattsaxon: is the expectation that people will attend them all
<nick_s> skeptical manu is skeptical
nicktr: no, but people will attend the late/early one if they feel they need so
manu: (observes that most WGs start like this but change if participation drops)
shepazu: let's start this way but I agree that often the participation drops off let's handle this when it happens
sub-topic: face to face
nicktr: do we want 2 or 3 f2f meetings next year
manu: there is a lot of other payments stuff going on, 2 is enough
nicktr: proposal then to do 1 near end Feb in USA (West Coast) backing the IG f2f and one other
padler: when will we start calls?
nicktr: propose we start calls week after next but will figure out a good time in the interim
<Zakim> padler, you wanted to ask when we start calls?
<nicktr> ACTION: nicktr to set up questionnaire to find best day for weekly meetings [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action03]
zkoch: I like the idea of meeting more often than every 6 months (i.e. more than twice) as I think we'll need it
<adrianba> +1 to meeting between feb and tpac
<nicktr> +1 to meeting between feb and tpac
shepazu: perhaps we should try to
meet at a time and place that members are already getting
together
... and then also TPAC
nicktr: feels like there is a desire for a mid-year meeting but let's put off planning that for now
dezell: if we don't plan the Feb
meeting now we might not
... we also need to make a list of events that makes sense for
us to all attend (this was a task the IG planned to
undertake)
shepazu: TAG suggest that W3C WGs try to engage with the public more. I recommend that next time we meet we have a public event (dev meetup)?
IJ: IG relationship - future reviews, chairs can decide to meet from time to time; joint meeting end of February
Dezell: IG meeting weekly 10am ET Monday...planning to continue that for now
NickTR: Any other comments/concerns about running the group?
jheuer: I can't join the group officially for now; I hope the IG remains a place where we can connect
<zkoch> Feb 25, 26, 27?
<zkoch> Are those the dates?
<zkoch> Things are looking good to host
(Could be those dates or any time that week
<zkoch> I just need to submit a finalized request, which I’ll do today or tomorrow
<zkoch> Okay
<scribe> ACTION: nicktr to write up the group operations in a wiki (re email, issues, etc.) [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action04]
<trackbot> Created ACTION-1 - Write up the group operations in a wiki (re email, issues, etc.) [on Nick Telford-Reed - due 2015-11-06].
adrianba: Against my better judgment I'm volunteering to help NickTR with the work mode document
<nicktr> http://bit.ly/1NEkkz8
Nick: Timelines?
<nicktr> https://docs.google.com/document/d/1yJEba_BCUK0Q1nCaD2sGM4h6HxxxEcT15ruRlvowr7o/edit?usp=sharing
Manu: 1 month?
adrianba: I've learned a bunch of
lessons from the discussion and that inform the feedback on the
proposal.
... my goal is that we take those lessons and incorporate them
as soon as we can.
... I don't think I could predict a good time frame for making
a decision on the future of the alternate proposals.
... but if we weren't having substantive discussions comparing
the proposals in November then I think we would be failing the
group
AdrianHB: So we need a milestone for "feedback has been incorporated"
m4nu: There are big issues we
need to resolve like "does linked data play a role?" or "is
remote storage in scope?"
... by having those discussions I think they reflect what's
actually in the proposals.
... I don't think the specs need a full rev before we start
discussion of the stickier issues
... we can rev the specs quickly while we are having the
discussions
AdrianHB: How do we feel about
documenting issues in github
... i mean the high-level discussions
... I there will be issues in the web platform github repo, as
well as issues that are more general in the Payments WG github
repo
adrianba: I like what I just
heard. It would be good if we could start to capture those
general issues in the general repo and use them to generate
agenda items for the calls
... it's incumbent upon us to make a start on that.
<AdrianHB> ian: let's allow anyone to also submit issues
<scribe> ACTION: AdrianHB to start documenting general issues and inform WG of initial pass so they can add to the list or add comments [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action05]
<trackbot> Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
adrianHB: Then we can prioritize
them based on the ones that are getting the most
discussion
... I think we have a good todo list.
IJ: I think a good way to use meetings is for people to work on proposals, for us to review proposals before meetings, and use meeting time to review comments
Adrianba: I think there is
agreement we should discuss the various kinds of
registration.
... but I don't agree we've decided in which forms there should
be
AdrianHB: Anybody want to step up to lead discussion on registration scenarios?
<scribe> ACTION: adrianba to write up list of registration scenarios he he mentioned in more detail [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action06]
<trackbot> Created ACTION-2 - Write up list of registration scenarios he he mentioned in more detail [on Adrian Bateman - due 2015-11-06].
Laurent: I think we also agreed to define a payment request data format.
AdrianHB; Registration request as well
RESOLVED that we agree upon the following summary
<rbarnes> https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
<rbarnes> for context: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
NickTR: Thank you to all! I hope
you will continue to participate
... do your actions
... we will only be successful if we move things forward
... I look forward to meeting you on IRC, WebEx (and of course
github)