Web Payments Working Group

07 Nov 2017

Agenda · 6 November minutes


Gildas, oyiptong, Rouslan, Ian, bertrandjeannet, Aiki, andrewsudbury, Etienne, btian, mdadas, alyver, Max, ryanwatkins, dlongley_, Rodrigo, Dongwoo, Manu_Sporny, nicktr, jgipson, MANASH_MC, Manash, John_Best, Keyur, dezell, David_Lim, marconi, jean-yves, vincentK, frank, voisine, James_MC, jmacwhyte, Magda, lin_li, Brian Piel, Rahul Deshpande, Robert Reany, CyrilV
Ian, manu, nicktr


<Ian> Scribe: Ian

Payment Method Manifest

[Rouslan Slides]

Rouslan: Payment Method Manifest - allows us to authenticate payment apps and allow payment method owners to delegate authority to payment app distributors
... we would like to go to FPWD
... we have implemented PMM in Chrome...it is being used by Tez (India) and Samsung Pay
... Chrome looks for a payment method manifest (by using a header)
... there have been some concerns about leakage between payment method identifier and manifest
... we decided a year ago to go with HTTP Link header
... The contents of the payment method manifest are JSON
... contains different values including "supported_origins"
... this tells Chrome which payment app origins can fulfill this payment method
... note that "*" value means "any origin"
... this could be useful for open payment methods

AdrianHB: What is the behavior if you get no response?

Rouslan: Denial

Manash: Does manifest file cover both mobile and web apps?

Rouslan: Yes

Mountie: Is "Localhost" supported?

Rouslan: We started by not supporting localhost; we heard people wanted it, but there are challenges in supporting it all the time so we may treat this as a flag that developers can turn on to support localhost
... Another bit of information in the manifest: a list of default applications
... though are URLs to web app manifests
... Final, supported_origins is a list
... (where "origin" means scheme, domain name, port if non-standard)
... this is useful for use cases such as an organization that certifies payment apps

[IJ thinks that Masterpass is in this category]

[Rouslan shows a Web app manifest]

Rouslan: in the case of android payment apps, the fingerprint is used to authenticate the payment app
... We got some interesting feedback based on deployment experience:

  1. Need more logging. I originally came from the computer security world where you don't want to give tools to attackers
    ... but unfortunately when you are setting this up and it requires some debugging, need to be able to see in logs
    ... suggest to put info in developer tools
  2. Allow localhost development
  3. Respect HTTP Cache header

Rouslan: Caching needs will differ

Manu: Has anyone talked about putting these manifest files on a CDN?

Rouslan: We've not thought about it but could be done I guess.

AdrianHB: Do you respect redirects?

Rouslan: No.
... we want to be as strict as possible
... your CDN could be non-redirecdting
... Questions

  1. Hosting a manifest. From our experience hosting has not been a big burden
  2. Regarding HTTP headers ... we have heard some critiques to this approach. However, our plan is to stick with HTTP headers approach (also used for server workers, for example).
  3. Privacy issues - user IP exposed to manifest host. IF the user's browser fetches manifest file, host of manifest gets user IP address
    ... so what we do is we only download the manifest if the user has an application that uses the manifest
    ... we deem registration of a payment app that uses a payment method to constitute approval to interact with the manifest
  4. Merchant origin exposure to manifest host. Currently when we download the manifest we don't tell the manifest host why we are downloading it
    ... there is no referer header in the request
    ... one question has come up - what if there is a misbehaving merchant site (e.g., they've been hacked) that is trying to DDOS the payment method manifest host
    ... should the manifest host have the ability to block requests
    ... this would be possible if we set the referer header
    ... in our experimentation, performance is good even without pre-caching, so we COULD use referer header.

Nick: Can a fingerprint apply to multiple versions of an app?

Rouslan: Yes, in android pay store

Manu: +1 to going to FPWD
... who else is going to use this?

Dongwoo: Samsung

Sachin: MasterCard

NickTR: No objections to moving towards FPWD

<scribe> ACTION: NickTR to help get Payment Method Manifest to call for consensus

Credit Transfer

[Credit Transfer Slides]

Cyril: We have several payment methods. We built two for two general types of Credit Transfers: Payer-initiated and payee-initiated.
... the third is specific to the PSD2 context
... each payment method defines data sets (based on data models from other standards)
... payer-initiated credit transfer raises a security issue - fraud might lead to wrong merchant account number.
... so payee-initiated intends to address this concern
... payee gets a token and allows the merchant to use a token to initiate payment
... there are still issues (e.g., token needs to be sent quickly, otherwise risk of double spending of amount in the account)
... but a bigger issue right now is whether there is support from banks for this type of API
... so with these issues in mind, in PSD2 context we have another payment method (PISP) that leverages relationships and validations that exist in the PSD2 ecosystem
... the PISP payment is a simpler data flow
... but primarily the big benefit is that the merchant IBAN is not sent over the Internet
... there are different flows that we can imagine (e.g., at which moment user authentication takes place)
... the PSD2 bank APIs will be open APIs, so we can experiment with different flows
... there are several open bank APIs efforts (e.g., Open bank in UK, STET, Berlin Group)
... next in the presentation: Matt will show experimentation by Worldpay

[Matt Saxon slides]

MattS: We updated our three payment methods and then decided to do some experimentation
... In the UK we have an open banking API
... the API will be available for production use in Jan 2018
... the API is not yet PSD2-compliant, but they do plan to do that by adding 2-factor auth
... Worldpay is an acquirer / processor; we help merchants accept payments from shopper
... there's no place in the PR API that acknowledges processors. So it's an interesting question for us to see whether we can use PR API to increase conversions
... we considered the three payment methods in conjunction with the open banking API
... we could have also implemented our own payment method (and had we done that, we would have used a payment method manifest)
... for this experiment we chose the open banking API, which supports a split authentication and execution
... we also tried an implementation that does not use PR API
... since PR API not entirely deployed


<Jalpesh:> is it ok to take the video of the demos, when presented in the room?

<Matt:> Yes.

Matt: In demo of traditional flow: pick a bank, identify yourself, choose an account, confirm details, and payment confirmed
... In version with payment app: You open the sheet, choose account, push the "Pay" button
... then another screen appears (you are in a payment app)
... at the moment it's difficult to differentiate that you are in a payment app
... this is important
... we would likely show N registrations (one per bank)

AdrianHB: Could you skip a step in practice if you just have your own bank?

MattS: Yes, depends on registration
... What you saw today suggests that the user experience between "without PR API" and "with PR API" is very similar today; the "with PR API" will need to be improved

[Review of the payload]

Matt: The open banking API does not use ISO 20022, so there is some challenge in mapping data from the credit transfer spec (which refers to ISO 20022). The Open Banking API would like the delivery address.
... the most important reason is fraud mitigation....e.g., compare cardholder address with shipping address.
... but the payment app does not receive shipping address (via Payment Handler API)
... there's also a concern that payeeAccountNumber could be tampered with
... that's the primary motivation behind the PISP payment method design

[Discussion of signatures]

Cyril: Worldwide PKI is hard to achieve
... PISP is easier to achieve (maybe 100 PISPs in europe)

<AdrianHB> The need for delivery address as input to the UK Open Banking API suggests we should find a way to solve issue 123.

[MattS walks through various mappings between w3c data model and Open Banking]

Matt's observations:

Matt's suggestions for WG next steps:

Interledger Payment Method

[AdrianHB slides]

AdrianHB: ILP is for internetworking different payment networks
... for payment request, focus is on standards, not internetworking: addressing, reconciliation, proof of payment
... payment method identifier is interledger
... request data includes address, amount, condition, data
... we have an addressing scheme that endeavors to make it possible to address any account in any ledger
... the hierarchical approach assists routing
... We used a normalized amount (64-bit unsigned integer)
... and we have a "scale" based on the receiving account address
... so scale for USD is 2; scale for bitcoin is 8
... finally, last two pieces are condition and data
... when the payee sets up a payment request, the payee attaches the condition to the payment request. Data is used to provide integrity protection

Manu: What org manages the hierarchy?

AdrianHB: Ecosystem-defined

Manu: How do you avoid name collisions?

AdrianHB: Because of the way a protocol works, you can't claim to be someone you are not without proper crypto
... There is a whole spec on addressing
... very little of this as specified has gone beyond the Community Group
... the condition is a sha256 hash of the fulfillment
... payee has a secret
... sha-256(payment data + secret) = fulfillment
... sha-256(fulfillment) = condition
... payer gets back a proof of delivery of payment (useful for reconciliation)
... the fulfillment is common across nodes; to help with certainty that payment has been delivered


AdrianHB: As merchant I can verify that the fulfillment matches the condition, so I know that the payment has been delivered.

Keyur: Who is responsible for converting between currencies?

AdrianHB: As the sender, I can go to the network to get quotes (and choose least expensive mediator based on, e.g., conversion rates)

Encrypted Card

[Olivier Yiptong slides]

oyiptong: Rationale for encrypted card is PCI DSS compliance
... lots of horror stories about PCI DSS compliance
... It's hard to become PCI-DSS compliant and EVEN HARDER to maintain compliance
... review of study done by Verizon on breaches and lapses in security
... summary: it's difficult and costly to remain compliant
... but PCI-DSS compliance is pretty useful; it enforces some good practices
... it's good for merchants to reduce scope
... for merchants there are three main compliance levels we care about: SAQ A, SAQ A-EP, and SAQ D

[Olivier looks at the eligibility criteria of each, whether ASV scan is required, penetration test required, and number of questions]

SAQ A: 22 questions

SAQ A-EP: 191 questions

SAQ D: 329 questions

oyiptong: Basic Card used as-is would require SAQ A-EP.
... in the tokenization task force we have looked at a journey:

[Olivier shows different flows and PCI impact]

oyiptong: One option is for the merchant to provide a key through PR API. We could use trusted third parties to generate the key, which could be validated by the processor
... Instead of the merchant providing the key, the merchant can designate a key provider and the browser can fetch the key (and cache it)


oyiptong: note that the data is encrypted (otherwise similar to basic card)

[oyiptong shows payment request data and payment handler service worker registration]


oyiptong: Here is my ask!
... I think it's worthwhile implementing this directly in the browser
... if it's treated like basic card, it will help increase security and make PR API mainstream

IJ: One proposal to increase security is to have the user agent (or payment app) fetch the key rather than having the merchant pass it directly.

Jenan: We recently released our integration with PR API. We solve this problem with same tooling.
... Stripe PR API initiates payment request from an iframe.
... that solves PCI scope for Stripe merchants
... we further add value beyond mere encrypted blobs
... So we don't think this adds value to Stripe merchants since we solve for it.
... furthermore, you can't encrypt the CVC per PCI rules (I think)
... one answer to that is potentially not do client-side encryption but encryption is merely posting data to a server...in essence replicating our API
... our experience is that we've seen calcification in the past when multiple parties have had to agree to a single API
... we have preferred to keep an evergreen approach

oyiptong: Thanks! Regarding implementation by using an iframe - it is possible to use an iframe...but the value here is if browsers implement.
... I think this would compete with Stripe's implementation; that's a fair point
... on your second point (not encrypting CVV)...I thank you can encrypt it but not store the CVV

NickTR: I am not aware of requirement not to encrypt; but you can't store it

CyrilV: This means that when I use my card with a merchant for the first time, the card data is encrypted (and could be stored for use each time with that processor)
... that might scale well because the number of processors will be small
... so this seems interesting to me.

Manu: +1 to encrypted card payment method
... would be great if we didn't do basic card at all
... We could deprecate Basic Card at some point

Marcos: Maybe, but there are a million systems out there

mweksler: Think of the conceptual framework of nothing leaving the browser unencrypted
... we should be able to get the data out of the browser without exposing it

jean-yves: +1 to Encrypted card proposal

shift4sms: +1 for Encrypted Card
... and would be great to deprecate basic card as much as possible
... regarding CVV...you can encrypt it and technically even store it pre-auth
... the only 2 things I would add to the data method is the expiration date (e.g., to ensure card is valid for a reservation three months from now) and the other bit of data is the 8-digit prefix; some people do routing based on card bin
... PCI-DSS is evaluating how secure iframes are

etienne: +1 to encrypted card

Giulio: A couple of questions - what is the additional work required of the browser?
... I also note that tokenization and encryption might co-exist

oyiptong: The problem of tokenization is that we need to standardize the communication between servers.

Ian: Regarding what the browser does - it would optionally fetch key, then encrypt in CPU

MattS: Why not extend this beyond basic card to allow encryption of any payload?

<nicktr> is having an allergic response to 250000 key exchange ceremonies with each merchant

AdrianHB: An alternative approach is pass in a certificate (not just a public key) and for the certificate to be the identify of the merchant. You would as a merchant to have a signing cert; and you could give private key to your processor
... the idea is that when the payment handler gets the request and looks at the cert, they see that the origin of the cert and the merchant is the same
... there may be additional options as well

jenan: To reiterate - I think it's important to distinguish security from PCI compliance.
... I'd love to see a concrete proposal regarding the cert
... and to hear from browsers whether they are interested in implementing this
... I think the proposal as it stands today doesn't solve security....
... unless there is some presentation of the source of the encryption key to the user, or some sort of whitelisting, or some way to know who is doing the encrypting, it's not materially better than today

<dlongley_> also, don't have to use the public key from the merchant's certificate to encrypt, could use the issuing certificate's public key (either presumably the PSP or explicitly indicated)

<jenan> also: would be useful to answer in finality what the "saq-a v. saq-a-ep" implications of encrypted cvc (etc) are. We could be interested in something that provided that security and where there was interest by browsers to implement

<shift4sms> Re: Encrypted card. Some concern on pub key served by merchant site cannot be trusted -sites can be hacked creating a man-in-the-middle hole. We’ve discussed this quite a bit internally (@Shift4). Without a payment app and merchant “certificate like” authority, not much effort should be given to plugging “site hacked” hole because a hacker can do pretty much anything, with or without man in middle. Simply changing payment method from encrypted ... PKI man in middle attack and just as effective.

NickTR: I am hearing there is strong support in the room for looking more into this payment method

Network tokenization

<manu> scribe: manu

JamesAnderson: Mastercard, joined for a number of reasons - we care about ubiquitous usage, simplified contextual user experience, security with scale...
... This means we care about tokenization.
... We're trying to make the ecosystem secure... dynamic payload... that's a big part of network tokenization.
... We're trying to reinvigorate 3DS... consumer auth protocol... answers the question: is this the user? There was a 1.0 of 3DS, but it was no longer fit for purpose.
... We went through 3-year effort to make it fit for purpose now... got to 3DS 2.0 - bringing this to W3C, gives us benefit of security at scale.
... There are standardized already, wanted to bring them into W3C... not onto the Demo.

Manash: What we did in the last 3-4 months - we looked at how you create a good UX... leverage wallets that are already out there, built it on top of payment request.
... We have a demo - AirBnB experience... basic card, custom payment method... what if the PR API can say I support all wallets that can return network-based tokens. In terms of discovery, all those that become a standard payment method will discover it.
... When I click "book", I see all apps that support standard network token payment method... I click pay and can pay.
... J Crew have already implemented Payment Request API... and you've added an item... checkout now supports PR API
... Network tokens could be standard payment method... it'll show masterpass as a standard mechanism... lowers the merchant implementation costs... makes it very standardized for discovery.
... Why are we doing this? There are gaps with Basic Card... it's not secure, increases PCI scope, bad UX - CVC... any bad steps hurts conversion ratio.
... one in six transactions will be declined. If merchant wants something more secure, they can do custom payment method.
... You could integrate with alipay, samsung pay, apple pay, etc. Apple Pay only sends back transaction ID -
... Network tokens fix this issue... multiple different native apps can send back standard tokens back to merchant...
... Sachin will go through network token specs... what other partners can move forward and help w/ token spec?

<scribe> scribe: Ian

Sachin: Walking through the Tokenized Card Payment draft. Keys will need to be certified
... I would like to discuss that further
... when the TSP gets a request for tokenized card, they encrypt it with public key and that they have seen in the past
... they have already onboarded the entity

[We review the request and response data]

Sachin: Note that the response distinguishes display data v. token data
... Encrypted Tokenized Card ensures your PCI DSS status

shift4sms: What happens when the PAN is compromised? Are the tokens that were issued also compromised?

Sachin: That risk remains
... you can just deactivate token

James: Issuer can also send a new PAN that maps to existing tokens

AdrianHB: It is possible to request only encrypted tokens?

Manash: Let me do a recap:

  1. We create a standard token spec for network tokens
  2. We are planning to implement to experiment. That will give us a road to consensus
    ... this would allow payment apps to send back a standard token response and lower costs for merchants and increase scale

Sachin: We were thinking of adding encryption on top of tokenization as a PR API extension

jalpesh: What is the meaning of the token expiration date?

Sachin: Each TSP can decide what it should be
... what we have tried to do from this is distinguish "display content" from "payload"

Jalpesh: I bring it up because in a tokenization world, expiration data may not be relevant. So why display it from a user experience perspective?

mweksler: How does this relate to card on file? This seems mostly useful for one-time payments

Manash: I think there are two layers
... right now card-on-browser is stored as basic card
... browsers could move to tokenized card.
... for merchants who have card on file - networks have a product that assists merchant to convert Card on File to tokenized payments; but I think that's outside w3c scope

NickTR: Acquirers also can do this

mweksler: I think it would be great to figure out a way to onboard cards but also with respect to card-on-file processing

NickTR: I think the use case we need to solve for is enrollment

Keyur: There is also some one-time use data in the response
... (cryptogram)
... that's already in the spec

AdrianHB: I have a suggestion around nomenclature. I suggest avoiding the word "card"
... in the future the exchange could be same but without card

Sachin: +1

Manash: +1

shift4sms: +1 on deprecating “card”


[Robert Reany slides on 3D Secure]

Robert: 3DS has been reinvented in 2.0 (and now 2.1)
... I think that there is a good opportunity for what is being to discussed her to help user experience, even as we recognize that there is an extant 40-year old ecosystem. Regulators are imposing 2-factor authentication on banks
... on every transaction (or must decline)
... in some markets it will be required
... e.g., in India 2-factor is required for pretty much every transaction
... we are trying to work with the reserve bank....since there is more data available (FIDO, phone data)
... and you can safely improve transactions without step-up
... that's the sort of dialog we have to have with regulators
... another story in PSD2
... strong auth + risk-based assessment + risk-based auth
... my big message is "don't create a new great user experience without considering the regulatory expectation"

Brian: The D refers to Merchant/Acquirer domain + interoperability domain (networks) + issuer domain
... "frictionless" risk-based authentication
... FIDO auth should be part of the data package - auth has already occurred and we don't need to step up


Brian: how do we enable scale and streamline the entire end-to-end ecosystem?

Manash: What is 3DS 2.0 going to be important? One reason is regulatory requirements. if the merchant is using PR API they would also expect the browser or payment app to handle the 3DS 2.0 requirements....
... if that DOESN'T happen, each merchant would have to deal with it individually
... so for international adoption of PR API we need to take into account 3DS 2.0 and in a manner that is scalable
... as next steps, there is a design session during the Wednesday breakouts
... it would be GREAT to have browsers in the room for that chat
... and also merchant reps in the room to have an informed discussion of relation of 3DS 2 to various payment methods

Manu: What modifications are you expecting to make to payment request to support 3DS?

Manash: We will go into detail tomorrow
... instead of just returning basic card payload

weiler: When talking about the information you are collecting, do you have a full list of data you want? A lot of these things are fingerprinting...how do you fall back if we succeed in limiting fingerprinting?

Brian: Most of the data relates to the data already being sent back to the menrchant
... we will go into details tomorrow and look at data protection

Weiler: What is the option if user does not want to share data?

Sachin: Likely decline or step up

The conversation continued on 8 November in a breakout on 3DS.

Merchant Adoption

<nicktr> scribe: nicktr

Ian: Let's talk about branding
... this is super important for adoption
... about a year ago, we started a merchant adoption workforce
... we identified 4 priorities:

Ian: ... Time for the visual identity
...question: what is the goal?
... to be another button amongst a sea of buttons? No
... What we need is something analagous to the RSS logo
... we want it to scale across sites and platforms. The identity is not shown in the slides - still not cleared by legal
... here are some iterations
... please don't take pictures

[Ian shows images]

The HTML5 logo rollout experience will be instructive. If there is support for the logo, next we would finalize the identity and palette of images, buttons, FAQ
... legal clearance
... Comms strategy from W3C staff
... Suggestion is to unveil during CR e.g. Jan 18
... But we need member support to drive adoption

<sachinahuja> Reminds me of a transport logo or this transport logo.

Ian: Discussion - do we like it? Does it look similar to other things? Should it be a trademark? Trademark could affect licensing

????: is the concern that a rogue polyfill might use the logo (or not)

Ian: We weren't thinking of a rogue polyfill. The question is whether we want to have some authority to ensure there is a consistent and trusted user experience.

manu: we don't have this anywhere else
... by which I mean we don't enforce usage/conformance

AHB: we had logos but they weren't policed

Ian: that is correct

shift4sms: trademarking is important

CyrilV: we had something similar in France. We used a "sharealike" license

ian: HTML5 logo is CC-by 3.0 unported.

Ken: I personally like the idea of a logo, but I don't like this - it looks like crossed arms
... but it would be good to align to something visually similar to NACHA, for example, and mutually support each other's APIs
... My own perspective is that the symbol needs to deliver on something

Ian: Historically we have not allocated resources to police W3C logos (other than the main W3C logo).

<Magda1> *now we're going to start seeing it everywhere*

Ian shows black background logo - 15 likes in the room

Ian shows white "cut out" logo - 14 likes

Ian: does anyone really hate this?

<Zakim> manu, you wanted to wonder why we don't try to integrate w/ HTML5 "logos"

Ian shows HTML5 turned into a dollar sign.

Ian: I was told not to mess with the brand
... also we're not in that HTML5 space anymore

Magda: we need lots of difference colours, formats

oyiptong: scalability is an issue (that is: it should work when very small)
... one seems more scalable (black bg)

Ian: I record Sachin really not liking it

Sachin: these are very generic and call to mind transit

keyur: can this be cobranded? It's going to be powered by browsers

Ian: Interesting question. Question to Microsoft?

????: Realistically it would be used just next to some other brand components

adrianHB: square not round please
... expectation is that this stands for a specific kind of experience
... it's more subtle than a big logo, it's more a cue

matt: Should this be "www payments" instead of "web payments"?
... I wonder whether we have decided to be web payments formally

Ian: We have not decided on a name but we did talk about it in the merchant adoption taskforce
... for a while we were going to call it payment request, but then "web payments" emerged
... we haven't made a formal decision
... Thanks for the feedback.

[We extend our thanks to Stephanie from the Microsoft Design team who did this work]

Next Face-to-face

AdrianHB: let's move things around on the agenda and do next meetings

Ian: TPAC 2018 takes place in Lyon from 22-26 October next year.
... it feels like we need at least one F2F before then
... and it feels like we probably ought to meet in Asia

<Magda1> *+1 Bali*

Ian: we could co-locate with Money2020 China?

AdrianHB: what time frame do people want?


AdrianHB: we should be looking at going to CR for Payment Handler Q2 next year and we have new payment methods to look at

Ian: I don't think we need to tie this to the charter renewal

AdrianHB: should we leave a gap between charter and F2F?

nicktr: we hope to recharter by end of Feb 18

AdrianHB: sounds like March to May window

Vincent: avoid school holidays in April please

Manash: end of March feels good. May sounds too late

Ian: anyone want to offer a venue in Asia?

oyiptong: we have an office in Singapore - let me investigate

Ian: we also have a host in China

ken: in the payments world, our T&E is planned a year in advance and we plan from May. So March would be good

<scribe> ACTION: nicktr, AdrianHB and Ian to work up a proposal on the F2F location

Privacy Topics

<Magda1> +1 for encryption to hot topics list

AdrianHB: does anyone want to dig into any specific topics?

nicktr: let's do data privacy and encryption

npdoty: yes, leaks incognito, but also whether you have specific cards which could be used for fingerprinting
... is the specification going to explicitly limit this or just rely on implementations

manu: has PING done any analysis on shipping address leakage?

npdoty: I haven't looked at that in particular. The implicit mitigation is that it only occurs when the payment sheet is visible on address and limiting to top level browsing context

AdrianHB: the big challenge with canMakePayment is that there's no user-interaction or hints. The mitigation is velocity

npdoty: can you mention any more detail?

AdrianHB: It's already there in the Apple Pay implementation. The purpose is to streamline the payment process so merchants don't call paymenbt methods that would need registration or introduce friction
... the sticky issue is whether the specification should comment on the velocity
... I think you only get one shot with canMakePayment

npdoty: would it be useful to find out if the consumer can support paymentRequest?

mattSaxon: because the ecosystem is complex with many payment methods, it's very challenging

npdoty: it's the driveby nature of this feature that makes it problematic.

AdrianHB: unfortunately we don't have the implementers but there was a bug

npdoty: there was also a problem with iterating iframes. I don't know whether that was resolved

Ian: I don't think we know.

AdrianHB: I think we need implementers here in the room.


Upcoming PAG

Ian: Patent Advisory Group will need to be launched given Visa patent disclosures
... these work by asking each participants to put forward people to join the group to review the patents that have been disclosed and/or excluded
... the next thing you will see is invitations to join the group

Manu: did they disclose then join?

nicktr: no, the other way around

AdrianHB - I propose we break for the day

nicktr: thank you everyone for a great couple of days
... three potential breakouts: encryption, HTTP API and IETF, signatures

Summary of Action Items

[NEW] ACTION: NickTR to help get Payment Method Manifest to call for consensus
[NEW] ACTION: nicktr, AdrianHB and Ian to work up a proposal on the F2F location

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/22 17:24:39 $