<SachinAhuja> let the games begin
<Ian> we are going to send payment handler people off to another room and do tokenization in this room with the mic
<Ian> Some resources for this discussion: Tokenized Card Payment specification, Encryption wiki, and AdrianHB's slides for this session
<Ian> [Adrian walks through the data example]
<Ian> ...today it works in the market like this:
<Ian> a) There's a token request
<Ian> b) Issuer makes decision based on data passed in whether to request additional info or do a challenge
<Ian> Dave: Is there a flow that shows an ID&V (Identification and Verifiaction) process?
<Ian> Sachin: The ID&V flow is important to call out; other parts might be able to be black boxed
<Ian> Dave: Might be worth walking through some mobile enrollment examples
<Ian> stpeter: My perception is that this was for a transaction step, but not the enrollment step
<Ian> (Nodding from MattS, Giulio that they shared that perception.)
<Ian> MattS: I'm not sure that's a problem...the aim of the tokenization spec was not to recreate other specs, it was just meant to provide a bridge
<Ian> ...what I think is missing is to clarify this for the reader (e.g., in the section 10 flow diagram)
<Ian> ...we are trying to standardize the data from an arbitrary payment handler
<Ian> AdrianHB: What assumptions do we have? One thing we want to standardize is to enable the merchant to refer to a key provider for encryption of the sensitive bits
<Ian> Giulio: What the merchant does with the token is outside the scope of the spec
<Ian> Dave: I understand the provisioning process is not in scope. The merchant might say "I accept mastercard" and if the payment application has gone through a tokenization process with the user, they can say "Here's your mastercard...it happens to be a token." It's syntactically just like a card
<Ian> AdrianHB: As a handler, you can register with the browser as handling both payment methods
<Ian> Dave: I am saying the handler registers for both, but only ever returns a token.
<Ian> AdrianHB: In that case the merchant only accepts 'basic-card'
<Ian> Sachin: Some merchants can't handle cryptograms
<Ian> ...and we think that token fields are not fit for display fields
<Ian> ....there are two parts to the response data:
<Ian> a) Displayable data
<Ian> b) Sensitive data is encrypted
<Ian> SachinAhuja: For PR API, can we talk about "requestor" rather than "merchant"
<Ian> [Discussion of terminology such as "payee" and "merchant"]
<Ian> ...how do we figure out which TSP to go to?
<Ian> AdrianHB: That is an open question ... who is the likely candidate as the TSP?
<Ian> ...can browsers be token requestors?
<Ian> Sachin: The token requestor could be a cloud token for the PSP, etc.
<Ian> Q: How do we figure out who the TSP is given card information as input?
<Ian> Dave: It's based on the BIN range. If a payment handler can tokenize a card, it will know which TSPs to reach out to
<Ian> AdrianHB: If the payment handler is not from the issuer, how does the issuer connect to a TSP?
<Ian> MattS: the assumption in the spec at this moment is that this is network tokenization
<Ian> ..the payment handler is either from Visa or issuer that has relationship with Visa
<Ian> ....the mapping is that the handler and the network are the same
<Ian> ...we did consider other scenarios, but the spec does not deal with other scenarios at the moment
<Ian> stpeter: I would mostly agree with Matt that there's a relationship between the handler and the issuer/network
<Ian> ...I don't think that that has to be because the payment handler comes from the issuer
<Ian> ...that could happen at enrollment, for example
<Ian> AdrianHB: The merchant does not see the token in the clear
<Ian> MattS: That's my assumption.
<Ian> ...the merchant points to a key. This enables the acquirer/gateway to provide a key so that the encrypted data cannot be seen by the merchant
<Ian> AdrianHB: Can the merchant choose to NOT provide a key (to avoid encryption)?
<Ian> stpeter: Regarding "why not just use basic card"...if the merchant accepts tokenization, maybe they know that they are not getting PANs, which might be desirable from a PCI standpoint.
<Ian> AdrianHB: There are 2 solutions wrapped in one here - how to define a data dictionary to allow for tokenization, and how do we allow token requestors to request that the response be encrypted
<Ian> IJ: some of the broad questions for the group:
<Ian> - do we have the right data model?
<Ian> - who will implement this? Will browsers?
<Ian> - do other *Pay systems want to converge on token format we are talking about?
<Ian> stpeter: It seems to me that the browsers are going to want to do this based on conversations we've had before (at least google and mozilla)
<Ian> ...there's value to the browser in doing the right thing and in providing user security
<Ian> ...payment handlers could also do this
<Ian> ... that doesn't get to Ian's holy grail of the standard token format
<Ian> Giulio: To summarize my understanding of the tokenization project: after basic card, can we increase security through tokens?
<Ian> ....the browser has the card on file and would become a token requestor
<Ian> ...and return a generic token that can be used with multiple requestors
<Ian> ...I understand the networks support other types of token that are merchant-specific that don't require a cryptogram
<Ian> ...we need to discuss whether that use case needs to be supported
<Ian> ...I can think of use cases where the generic cryptogram doesn't work very well
<Ian> ...e.g., subscriptions
<Ian> ...there is no request for dynamic cryptogram each month
<Ian> ...if we want to use different types of tokens we should think about that.
<Ian> AdrianHB: That speaks to the "data requirements" question...do we have all we need?
<Ian> Giulio: The other thing is in terms of data exchange between token requestor and the browser
<Ian> ...we [Apple Pay] let the merchant specify the type of cryptogram that they are looking for.
<Ian> ...there might be different cryptogram types
<Ian> Dave: Why would the merchant care about the type of cryptogram?
<Ian> Giulio: In Apple Pay there is a system that supports 3DS CAF that's supposed to migrate to something else, but that migration is not happening all at once
<Ian> ...so it could be that the app can create either one, but the PSP might not be ready to take the EMV one yet
<Ian> ...so the merchant should be able to provide the input filter
<Ian> MattS: When we started talking about tokenized card we found the term "tokenization" overloaded
<Ian> ...the original intention of the spec was to do everything together.
<Ian> ...but that proved unwieldly
<Ian> ..so we simplified
<Ian> ...I don't want to quickly add use cases back in
<Ian> mweksler: Do we have a concrete use case in mind then?
<Ian> mweksler: It will be a while before we get to tokens; I think a general purpose non-scoped token is NOT what the networks are pushing for.
<Ian> ...I think more useful to merchants would be to have merchant-scoped tokens that are used for card on file.
<Ian> ...I think that would be more useful
<Ian> MattS: The way I've imagined this happening is that you keep the specs small and focused and then combine them as needed
<Ian> stpeter: I want to echo Matt's comment ... we have a lot on our place and so being able to solve a smaller problem would be useful
<Ian> ...I'm interested in the role of the browser here to get data back to the merchant
<Ian> ...I'm less interested in some of the (important) use cases like card on file
<Ian> IJ: Regarding *Pay implementations converging on a tokenization spec, one of the ideas was to enable the *Pays to work with merchants who have not yet signed up, but who are prepared to accept network tokens. For example Apple Pay could support 'tokenized-card' and Apple Pay could be then used with merchants not yet signed up (so more business opportunities and happy users can use Apple Pay frequently). I realize this is ignores other issues (e.g., liability) but am wondering whether it would make sense.
<Ian> Giulio: I am hearing mweksler say....suppose the merchant replaces a card-on-file database with merchant-specific tokens
<Ian> ...wouldn't it be great for guest checkout where the browser provides a token which would work with that?
<Ian> ...but what we're saying here is not that...the browser returns a generic token that works across merchants
<Ian> ....but presumably that token would not be reusable
<Ian> Issac: When a merchant wants a token, they still want a network token
<Ian> ...the question is how to work with it
<Ian> ....[agreement on that point]
<Ian> mweksler: Merchants are going to want to continue to do card-on-file transactions; they have an ecosystem to deal with that
<Ian> ...there's a lot already built to deal with this
<Ian> ...I think the onramp is smaller by going through card-on-file
<vkuntz> See the very good paper from Gemalto on "channels" for tokenization
<Ian> AdrianHB: I am hearing people put forth an argument that this spec as it stands does not add sufficient value beyond basic card
<Ian> ..if we want stakeholders to get more excited, we need to add more than just tokenization
<Ian> MattS: I am hearing 3 different tokenization use cases
<Ian> 1) Michel's use case: Card-on-file with reduction of PCI scope (for recurring payments and other use cases)
<Ian> 2) MattS's use case: Guest checkout, for first-time and one-time use
<Ian> 3) Ian's holy grail: Generalization of existing third party wallet tokens
<Ian> MattS: Who thinks which of the 3 scenarios is the most important?
<Ian> stpeter: I'm not sure what the card-on-file checkout use case is
<Ian> ...I think that the generalization around single token format is extremely compelling; interesting security properties
<Ian> ...if we decide to drill into card-on-file, worth looking at Oauth 2
<Ian> ...we could to things with delegation of tokens
<MattS> I think that oauth could help us build on 1-time use
<Ian> AdrianHB: I think that recurring use token is a solved problemn
<Ian> MattS: I think that's true, but in a very specific case
<Ian> ...Worldpay does this and our competitors do as well
<Ian> Dave: There are network tokens that can be used for recurring payments
<Ian> SachinAhuja: Regarding generalization of tokens, there is a spec out there (EMVCo Tokens)...that's all we are talking about...and everything else is flows
<Ian> IJ: My point about generalization was not to create a new format, but to see whether a tokenization spec could drive convergence by *Pays to lower the cost of merchant adoption of various flavors of tokens (but all grounded in EMVCo tokens).
<stpeter> for the record: I was recommending OAuth2 just to illustrate the pattern - the specifics of how that works for payments would likely use different syntax and semantics
<Ian> AdrianHB: I am hearing that specification might need to include this additional request data:
<Ian> - scope of response data
<Ian> - cryptogram type
<Ian> - token requestor id
<stpeter> Question: by one-time use token, do we mean obtaining a token out of a PAN without prior enrollment of the payment instrument with the token service provider?
<Ian> MattS: Guest means "not enrolled, not to be used again"
<Ian> Giulio: I think AHB asked for a show of hands about preferred use cases
<Ian> ...though I am not a merchant I think typically merchants are interested in easy guest checkout
<Ian> ...if they don't have card on file they would like to expedite checkout without registration
<Ian> ...so the use case of the generic token from the browser does that
<Ian> ...I think whether what a merchant has on file is a card or token matters less then losing potential customers
<Ian> mweksler: I think there is a range of merchant needs
<Ian> ....airbnb falls in the category where guest checkout is not a huge benefit
<Ian> ...I think card on file is much more appealing
<Ian> ... Another topic more unique to large merchants: there's more sensitivity about depending on a single PSP; this might be less important for smaller merchants
<Ian> ...having the network tokens that you can process becomes more important for some larger merchants
<Ian> AdrianHB: I think in that context, PR API is mostly targeting those who will process the response.
<Ian> ...e.g., the PSP calls PR API
<Ian> ...in general
<Ian> mweksler: Agreed
<Ian> MattS: I agree with the point on merchant diversity
Ian: Attempting to
synthesize
... 2 use cases that seem to be prominent (guest/one-time-use,
card-on-file)
... we need to understand the required input data
... we are talking about EMVCo tokens
<Ian> Q: Can someone request a token scoped to another entity?
<Ian> mweksler: There are use cases for that
Ian: token requestor CAN be different to "merchant"
<Ian> ACTION: Sachin to articulate token requestor concept
<trackbot> Created ACTION-90 - Articulate token requestor concept [on Ahuja Sachin - due 2018-04-27].
AdrianHB: I.e. The token requestor is part of the ecosystem and "allowed" to request tokens. The "merchant id" is a way to scope the token.
mweksler: We should avoid adding
too much granularity in the recurring token request
... i.e., specifics about the scope such as "number of uses"
AdrianHB: we are avoiding catering for all token properties so we can realistically filter out handlers before handing over the request
MattS: There are some filters we can't get around like expiry
Isaac: Some of these things (like token requestor) are well defined formats in the spec
SachinAhula: We need to clarify what we mean by scoping
<Ian> mweksler: Relates to routing of money (to that merchant)
<Ian> SachinAhuja: Maybe it should be more generic to allow for different scoping opportunities; merchant id just being one of themk
<Ian> Giulio: Browser can pass both top level domain (origin) and merchant id to the TSP
<Ian> ...that can be used to validate the information
<Ian> ...a merchant id could include more than one top-level domain but they might want to use the same merchant id for tokenization purposes
<Ian> mweksler: I am ok with more generic name, as long as merchant is called out as a key example
<Ian> MattS: EMVCo talks about "merchant identifier"
<Zakim> mweksler, you wanted to mention "account updater" at some point
<Ian> mweksler: tokens useful if cards lost/stolen
mweksler: one of the benefits of tokens is that they can be refreshed. We may need to identify a way that allows the token holder to refresh tokens
MattS: We'd like to have encryption as an optional thing that is also useful for other payment methods
Ian: We need a spec for
encryption
... the question that was raised here is: should encryption be optional in tokenization?
AdrianHB: Are there sandboxes that would allow people to build a prototype?
NickTR: The issue is end-to-end. There are multiple parties involved (get the token and use the token)
<Ian> Roy: I hope to have some help working on this this summer
<Ian> ACTION: Ian to update the tokenized card payment specification based on conversation
<Ian> AdrianHB: We are defining a data model for the EMVCo token request/response data model
<Ian> ....the implementation of going out and getting the token and returning it could be done by a third party payment app or the browser
<Ian> ...unless browsers plan to do this, I suggest we use a URL-based payment method to benefit from just-in-time registration
Editor's Note: After both the Tokenization and PR API Editor breakouts, we reconvened to talk about tokenization with the browser vendors. In particular, we raised the question of whether there is any appetite for browsers acting as token requestors.
<Ian> zkoch: Whether it makes sense for the browser to be the token requestor, I would say "ideally no"....we would offload to payment handlers to request tokens. Regarding deployment and adoption, the more limiting factor is that hte merchant needs to accept the tokens; that is more limiting than users getting payment handlers
<Ian> NickTR: There's an economic question here....tokens are sort of free for now (irrespective of who the token service provider is).
<Ian> ...but I believe it will become a revenue stream
<Ian> ...it makes sense to me that where the tokenization occurs, it will be the domain of some provider that somehow makes money
<Ian> ...I think that asking browsers to tokenize every time might be organizationally difficult
<Ian> zkoch: There are tokenized transactions in the wild; they manifest themselves as proprietary responses
<Ian> ....the opportunity is to set up the ecosystem so that handlers can reply in a consistent way
<Ian> AdrianHB: The motivation for browsers to do it is accelerated migration away from basic card.
<Ian> ....so the question is whether we can leverage browser implementation to get to tokenized card
<Ian> ...but I understand the incentives are different
<Ian> Sachin: When you are talking about W3C-defined payment methods....if a payment handler is installed that's great, but if it's not available, the mediator steps in to help
<Ian> ...whether to handle it or do a JIT install
<Ian> ...it's not about being a token requestor, it's that the browser helps find the right handler.
<Ian> zkoch: I like that framing
<Ian> ....broadening of the problem statement so that there's always something to provide
<Ian> ...I think there are lots of ways to achieve that potentially
<Ian> AdrianHB: I think it helps design the API if you know the ecosystem
<Ian> stpeter: I heard Zach say we want tokens to leave the browser but not have the browser be the token requestor
<Ian> ...I agree with that perspective
<Ian> Ken: How can we work together to achieve the goals of getting support for 3ds and tokenization; and moving away from basic card
<Ian> Giulio: Merchants don't wake up with a burning desire to use tokens. If it's better conversion they want, they might get that with just basic card.
<Ian> ...so merchants might ask "why do extra work for the tokens?"
<Ian> ...what are the other incentives (e.g., interchange)?
<Ian> ...or regulation?
<Ian> ...or a timeline by the browsers to deprecate basic card
<zkoch> Strong +1 to Giulio
<Ian> NickTR: I think it's useful to think about this 2 ways
<Ian> ...for the specific case of EMVCo tokens, the basic card spec needs extending .... and let the ecosystem figure out who will do the token requesting
<Ian> ...so I think that work is interesting for us to do
<Ian> ...we should concentrate on what the payload needs to be between the mediator and payee (for EMVCO type tokens)
<Ian> mweksler: I want to add a few points from the merchant perspective
<Ian> ...one thing that is beneficial in tokens that makes merchants eventually want to adopt them is to increase acceptance rates beyond what might be expected for basic card
<Ian> ...there is some extra data that gives the issuer a stronger signal that this is the real merchant and should increase authorization
<Ian> ...another benefit is that tokens are a pointer to an account, so the token can still function if card is lost or stolen
<Ian> ...if we are talking about "what we can do here"...I think the opportunity is that, "since tokenization is coming and offers benefits, we can make it easier to do"
<Ian> ....if we can combine tokenization with easy onboarding (e.g., issuer payment handler that can do strong auth)
<Ian> ...e.g., I think a great user experience would be to go to pay, pick an app that does strong customer authentication (SCA), and returns a token
<Ian> Ken: Can browser-stored cards be tokenized more easily with this payment method?
<Ian> IJ: Isaac, would built-in support for tokenization interest the edge team?
<Ian> isaacy: PSD2 is coming; if this is the right thing to do for SCA, then we would consider that
<Ian> Dave: TCH feels strongly that these new ways of facilitating payments should be tokenized
<stpeter> +1
<Ian> AdrianHB: I think there are two sides to this:
<Ian> 1) Supporting the necessary data exchange between "some parties"
<Ian> 2) How do we ensure that this is adopted
<Ian> ..in the case where the browsers are just passing the data along, how do we facilitate the propagation of payment handlers that support the payment method
<Ian> ...I am hearing the browsers right now saying that we should not determine the ecosystem; just determine the data requirements
<Ian> IJ: Here is my read of the conversation: (1) we should continue to work on use cases and the specification (2) browsers are not expressing interest in acting as token requestors (2) (3) therefore we need to focus on finding implementers ... who are not browsers
<Ian> stpeter: I feel it's a misrepresentation to say that browsers don't want to do things
<Ian> ....mozilla wants things to be tokenized...let's not overgeneralize
<Ian> Ian: Apologies; you have made clear that there is some interest from Mozilla.
<Ian> Sachin: It would be good for browsers to facilitate discovery of payment handlers that can do tokenization
<Ian> zkoch: There might be other parties in Google (than chrome) that might want to be token requestors
<Ian> AdrianHB: I think that a role for the browser might play is to help identify handlers at registration time (not transaction time)
<Ian> stpeter: Browsers ought to be emitting tokens...maybe it's an implementation detail that it's not the browser that requests them...they might invoke other apps to get the tokens (e.g., safari gets tokens from Apple Pay)
<Roy_> To clarify my stance, I view the browsers' implementation of tokenized-card (or basic-card) for that matter is a way to boost the ecosystem, but it is not their role as payment mediators to implement it, they chose to do so.
<Ian> NickTR: EMVCo has been working on Secure Remote Commerce (SRC). I think it is aligned with W3C ... there have been strong signals of support for SRC, including from Visa and MC this week. The Mastercard press release calls out w3c work as complementary. It's good to see that communication between orgs is happening. I am encouraged about work to get alignment between the work of the two orgs
ian: W3C and EMVCo work under
different confidentiality models
... there is a policy that staff can't sign NDAs for
example
... also that W3C WGs work in public
... so, for example, if the WG reviewed an EMVCo spec they
would have to release those findings publicly
... to date we have only discussed publicly available
info
... based on requests from W3C Members, we call out
SRC in our charter.
NickTR: The W3C stuff is public so anyone can see the direction we are taking. Anyone involved in both can try to influence W3C work to align with EMVCo
Ian: A desirable outcome (as with
FIDO alliance work) is that everyone is on the same page
... I believe FIDO and EMVCo solved the issue through an MOU
between themselves
<Ian> AdrianHB: Is there scope for EMVCo specs to be member submissions to W3C?
Ian: Historically there were 2
reasons to make member submissions
... 1) get something published by W3C
... 2) as a way to propose that a WG take up something as a web
standard
<zkoch> I'm not sure this conversation is super productive for the whole group. Proposal to move forward with agenda items and/or 3DS meeting? :)
<MattS> +1
<asolove> +1
Editor's Note: At this point, we did our last breakout session. A group of people went off to revisit the 3DS conversation that started yesterday. When they returned they delivered a 3DS breakout report.
<Ian> NickTR: Principally in the domain of PSD2. Two main pieces of PSD2 - open banking Apis, strong authentication (multi-factor)
<Ian> vkuntz: Three types of APIs -access to account info, access to transaction info, payment initiation
<Ian> NickTR: Biggest change in the past six months, is that the EU parliament has delegated responsibility to the European Banking Authority (EBA)
<Ian> ...the EBA is creating regulatory technical standards...the final versions have been published
<Ian> ...so now we have a proper framework for building solutions
<Ian> ...the regulatory technical standards are NOT API specifications
<Ian> ...so now there are a bunch of different competing organizations working on those APIs
<Ian> ...the requirement is to implement AN API not, that all banks implement the same API.
<Ian> vkuntz: There are three efforts in particular: Berlin Group, STET, and Open Banking UK
<Ian> ...we are working to align them all on ISO 20022
<Ian> NickTR: Why should you care? If you do no business in Europe, then it's only tangentially interesting
<Ian> ...but if you are a merchant with consumers who want to pay
<Ian> ......it's a seismic shift
<Ian> ...and I think it will move into other regulatory domains
<Ian> vkuntz: Due to opening of banks under PSD2 they are looking into building services on top of PSD2 (e.g., to compensate for revenue loss)
<Ian> ...one idea is the PayLater API
<Ian> vkuntz: Next week we will have a 2-day workshop to cover flows of this initiative.
<Ian> mweksler: Which financial institutions are represented?
<Ian> NickTR: This is a push payment from a loan account
<Ian> mweksler: It looks the same for merchant though
<Ian> vkuntz: It's a credit transfer initiated by the bank of the payer
<Ian> ...a goal would be to set up a payment method that supports this
<Ian> NickTR: ISO 20022 .... and we are aligning the credit transfer spec with ISO 20022...this is yet another use case on top of credit transfer
<Ian> MattS: Why would PayLater require extensions to credit transfer spec?
<Ian> ...the payment handler will hide some details
<Ian> ...I can see a new user experience but haven't heard that new data model is required
<Ian> vkuntz: We have not defined all the use cases yet; so won't know until we've done so
<Ian> Giulio: For the Web it's easy to imagine how this would come together....are they looking at other channels?
<Ian> vkuntz: I think the idea is to be able to build a new app with APIs
<Ian> ...but would be good to integrate with the work we are doing here.
<Ian> As a reminder, our specs are the Credit Transfer and PISP; our plan has been to combine them into a single document.
<Ian> MattS: Who else is going to the meeting?
<Ian> vkuntz: SWIFT, Google
<Ian> Harjender: Is the scope of that work exclusively ecommerce or does it also include physical POS?
<Ian> NickTR: That's a bigger conversation
<Ian> [NickTR describes the problem....physical goods v. shipping physical goods....]
<Ian> ...in a physical store you need to know in real time which is hard
<Ian> MattS: You talked about using w3c specs to drive some of this....any sense of who would implement?
<Ian> vkuntz: That's a question to raise in the workshop
<Ian> Giulio: It's not clear to me what the dependency is between PayLater and PSD2
<Ian> vkuntz: I think the thing was , since they have to implement APIs, they will have things in place so they can provide additional services.
<Ian> vkuntz: We have to start working on it...maybe of interest to our TCH colleagues as well
<Ian> MattS: There was also a question from someone in Germany about direct debit payment method
<Ian> vkuntz: We developed a SEPA-specific flow and a more generic one; but we need to review them
<Ian> NickTR: We are actively using the credit transfer spec in prototypes
<Ian> NickTR: So there is momentum in terms of interest but no changes to the spec
<Ian> vkuntz: And we have not yet put our 3 payment methods in a single payment method spec
<Ian> MattS: Still need to deal with tampering issue
<Ian> vkuntz: I think we need to finalize the specs
<Ian> MattS: see also the early discussion about signing payment request data.
<Ian> AdrianHB's slide deck on payment Pointers
<Ian> AdrianHB: The problem statement is how to define something like an email address that is easy to share and to be a target for payment
<Ian> ...we played around with email addresses + web finger but the problem with email addresses...is that they look like email addresses
<Ian> MattS: Today in Europe, in the UK there are account numbers...is the idea to have an indirection to allow for change?
<Ian> AdrianHB: Yes. It is also intended to be more generic (not country specific)
<Ian> ...for example in South Africa, I give an account number and something else
<Ian> ...if I want to translate that to something else, it's useful to have a layer of indirection on top
<Ian> MattS: The indirection is effectively a payment method account type
<Ian> vkuntz: EPC is working on a lookup service based on phone number
<Ian> nicktr: See also GSMA work
<Ian> AdrianHB: We have several layers of indirection. The following example payment pointers resolve to the specified endpoint URLS:
<Ian> $example.com https://example.com/.well-known/pay
<Ian> $example.com/invoices/12345 https://example.com/invoices/12345
<Ian> $bob.example.com https://bob.example.com/.well-known/pay
<Ian> $example.com/bob https://example.com/bob
<Ian> AdrianHB: The idea of the identifier is to suggest to people it represents a place to be paid
<Ian> MattS: Would $:// be a valid URL scheme?
<Ian> Roy: Is lookup a deterministic algo?
<Ian> AdrianHB: Yes
<Ian> MattS: I presume this was driven by ILP ... but also more broadly of interest?
<Ian> AdrianHB: Right; more generally interesting
<Ian> Shay: We have for now only integrated basic card support....
<Ian> ...for now only PR API integration; not yet done for hosted pages
<Ian> ...solution requires merchant SAQ-A PRCI compliance only
<Ian> ....domain separation applied
<Ian> ...pr api runs on bluesnap domain within iframe
<Ian> ...merchant uses token for the server to server paymenbt
<Ian> MattS: Did you run it in iframe for SAQ-A?
<Ian> Shay: Yes. We allow auto-create of payment button ....when web sdk is used
<Ian> ...the merchant can create a button
<Ian> ...the button will invoke PR API
<Ian> ...OR, the merchant can attach their own calls to the button
<Ian> [Demo]
<Ian> Shay: an issue is branding of button to make it recognizable to the user
<Ian> ...demo shows onshippingaddress change event
<Ian> ...another consideration...adding up the different amounts
<Ian> ...user is "blocked" while authorization process happens
<Ian> Shay: Upcoming work:
<Ian> - add payment request to blue snap's hosted pages
<Ian> - add alternative payment methods (e.g., Apple Pay)
<Ian> - integrate tokenized cards
<Ian> Shay: Some feedback on the API:
<Ian> - want a "buy now" button
<Ian> Ian: We have discussed a visual identity in the past; see the presentation at TPAC 2017. Those discussions have stalled, unfortunately.
<Ian> [Additional discussion here of configuring payment request based on user environment such as currency]
<Ian> ACTION: Roy to work with Ian to see if we can get volunteer resources for a pay with PR API design
<Ian> NickTR: We are prototyping an end-to-end experience with PR API, PH API, and WebAuthN
<Ian> [Nick shows the whole thing including tapping key]
<Ian> MattS: Open Banking involves passing a token back to the merchant
<Ian> ...so the merchant really does a pull
<Ian> ...merchant does not have access to account number; just a token
<Ian> [Demo in Firefox nightly using polyfill]
<Ian> ...but fails from polyfill since you can't invoke WebAuthn from it
<Ian> [Demo in Edge]
<Ian> ...sheet is a native windows application
<Ian> ...but doesn't support 3rd party payment apps so Open Banking payment handler not supported
<Ian> ...and in this demo, the auth mechanism is microsoft hello; software TPM authenticator
<Ian> ...it's FIDO-compliant
<Ian> ...it's exciting because you can jump into different authentication models with a similar user experience
<Ian> ...so it suggests to me that we are on the right track with our set of specs
<Ian> ...OpenBanking API is mandated in the UK
<Ian> Ken: Any interest in the US?
<Ian> NickTR: I would hypothesize that there is some movement but not as far along as in the UK or EU
<Ian> zkoch: The people in our breakout agreed on a couple of paths forward:
<Ian> - There's an opportunity to do more "privacy protecting" fingerprinting
<Ian> - Determine how can the browser make 3DS2 easier for some merchants
<Ian> ...browser vendors will go back to our orgs for internal chat
<Ian> Ken: Good session; thanks to people who participated
<Ian> ...we had an opportunity to present some of the things we see happening in the industry for level setting and alignment
<Ian> ...we covered value proposition including, e.g., regulatory activity
<Ian> ...rising need for multi factor auth
<Ian> IJ: Could you say more about the fingerprinting ideas?
<Ian> zkoch: Browsers don't like fingerprinting in general; but if has to happen, it might make more sense to do it on our terms. It's not about the data points; it's about consistent access to a fingerprint...with more control by the user and more transparently
<Ian> IJ: What relationship do you see between that topic and WebAuthN?
<Ian> Ken: Fingerprinting is definitely one of the primary topics we discussed today. I would like to raise that up a level and say that what we see in the industry is, as issuers continue to try to improve risk management; there's an open ask to collaborate on that
<Ian> IJ: What does it mean to make 3dS2 easier for merchants?
<Ian> zkoch: TBD
<Ian> ACTION: Amex (via Ken) and Mastercard (via Sachin) to provide JSON files to express flows
Editor's Note: Following the meeting, Marcos expressed his request more succinctly; now known as Issue 5: Communicating 3DS data in HTTP/JSON terms.
<Ian> ACTION: Browser vendors to hack up a prototype based on the provided flow and data
<Ian> AdrianHB: Cautionary note about privacy discussion
<Ian> IJ: But it seems like an opportunity, especially if the user has more control
<Ian> mcaceres: I have heard some people say that the browser vendors are not interested in this topic. I want to clarify that there is not a lack of interest; just busy on other topics
<Ian> IJ: Any way to keep more in touch on this before the next FTF meeting (e.g., at the ongoing task force calls)?
<Ian> zkoch: I think for 3DS the ball is in our court
<Ian> IJ: is there a date for reconnecting on this?
<Ian> zkoch: I don't think we can commit to a date yet; need to have internal discussions
<Ian> AdrianHB: One way to speed up work when one wants to see progress: show up with prototypes to communicate efficiently with developers
<Ian> mcaceres: Resources help...e.g., developers or funding for developers
<Ian> nicktr: It's been a while since we level set on current priorities
<Ian> ...I propose that the co-chairs develop a priority list and put it to the group
<Ian> ACTION: Nick to work with AdrianHB and Ian on a list of priorities for the next WPWG teleconference call
<Ian> Ian: And then we can blog about that
<Ian> AdrianHB: I think core work is more important than payment-method specific work.....e.g., getting payment handler finished
<Ian> NickTR: I found this meeting in Singapore very productive; thank you to all
<Ian> ...the chairs and team contact welcome feedback
<Ian> our next face-to-face meeting is TPAC in October in Lyon
<Ian> ACTION: Ian to send out schedule of upcoming calls
<Ian> For the full WG, the next call is 3 may
<Ian> NickTR: Thank you to Ripple for hosting!
<Ian> (Applause)
<asolove> Thanks all!
<Ian> ADJOURNED