IRC log of wpwg on 2017-05-23
Timestamps are in UTC.
- 15:30:02 [RRSAgent]
- RRSAgent has joined #wpwg
- 15:30:02 [RRSAgent]
- logging to http://www.w3.org/2017/05/23-wpwg-irc
- 15:30:05 [Ian]
- zakim, clear agenda
- 15:30:05 [Zakim]
- agenda cleared
- 15:30:11 [Ian]
- Meeting: Tokenization Task Force
- 15:30:13 [Ian]
- Chair: Ian
- 15:30:25 [Ian]
- Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017May/0057.html
- 15:31:20 [Ian]
- present+ Ian
- 15:31:22 [Ian]
- present+ alyver
- 15:31:25 [Ian]
- present+ SteveSommers
- 15:31:29 [Ian]
- present+ Christian
- 15:31:35 [Ian]
- present+ ClintonAllen
- 15:31:55 [Ian]
- present+ Olivier
- 15:32:12 [mweksler]
- mweksler has joined #wpwg
- 15:32:22 [stan]
- stan has joined #wpwg
- 15:32:37 [alyver]
- alyver has joined #wpwg
- 15:32:37 [stan]
- present+
- 15:32:49 [Ian]
- present+ michel
- 15:32:52 [alyver]
- present+ alyver
- 15:32:54 [Ian]
- present+ Roy
- 15:33:31 [Ian]
- topic: Stan's gathering of request/respnose data
- 15:33:36 [Ian]
- https://docs.google.com/spreadsheets/d/1v1BPvR7Z7apBrxSNgTF-ifYJAvLEECYh7tHW-cpSUq4/edit#gid=0
- 15:33:53 [Ian]
- stan: I catalogued different inputs/outpus
- 15:34:06 [Ian]
- ...comes with the caveat that I am not myself an expert in network tokenization
- 15:34:27 [ClintonA]
- I am not able to access the spreadsheet...
- 15:34:28 [Ian]
- ...having said that, there is some uniformity
- 15:34:34 [Ken]
- Ken has joined #wpwg
- 15:34:38 [Ian]
- present+ Ken
- 15:36:39 [Ian]
- stan: Major caveat...some of the gateways don't support a REST API publicly
- 15:37:04 [Ian]
- ..and stripe is moving toward not supporting tokenization through REST API publicly for PCI reasons...BUT moving to payment app would address that
- 15:37:20 [Ian]
- ....apple/masterpass/visa follow a similar pattern
- 15:37:29 [Ian]
- ...comes down to pre-agreed cert between merchant and PSP
- 15:38:06 [Ian]
- ...and output involves encrypted DPAN + cryptogram
- 15:38:16 [Ian]
- ...and when decrypted gives DPAN
- 15:38:37 [Ian]
- ...so gateways are pretty in alignment and the network-based are also aligned
- 15:38:40 [Ian]
- q?
- 15:39:15 [Ian]
- Manash: Apple pay => secure element. ...other cases can be cloud
- 15:39:34 [Ian]
- ...based on emvco standard, crypto can go into two fields
- 15:40:09 [alyver]
- +1
- 15:40:39 [Ian]
- Manash: PSP will have to mention the fields that they can take care of
- 15:40:59 [alyver]
- q+
- 15:41:03 [Ian]
- Stan: I am hearing that there's an input param from the merchant "what field acceptance"
- 15:41:07 [Ian]
- Manash: Yes
- 15:41:11 [Ian]
- ...we can provide some more details later on
- 15:41:25 [Ian]
- ...we are working on an EMVCo summary to share with the group that will have more details
- 15:41:46 [Ian]
- Stan: One interesting thing I noticed on Masterpass is that the request token needs to be created server side
- 15:41:57 [mweksler]
- q+
- 15:42:08 [Ian]
- Manash: Masterpass supports EMV token but we also support our own version of gateway tokens
- 15:42:16 [Ian]
- ...for merchants that want to reduce PCI exposure
- 15:42:21 [Ian]
- ..that leads to handshake
- 15:42:27 [Ian]
- ack aly
- 15:42:36 [Ian]
- s/+1//
- 15:42:53 [Ian]
- alyver: The merchants also have the responsibility in some cases of putting data in the right fields
- 15:43:01 [Ian]
- ...in UCAP or some of the EMV fields
- 15:43:06 [Ian]
- ...so not just gateways
- 15:43:12 [Ian]
- Manash: +1
- 15:43:15 [Ian]
- ack m
- 15:43:24 [Ian]
- q+ mweksler
- 15:43:35 [alyver]
- s/UCAP/UCAF
- 15:43:37 [Ian]
- clinton: This is my first call. Could someone describe the distinction between the two token types
- 15:43:54 [Ian]
- stan: I think the gateway tokens have existed for a long time...simple goal of removing PCI scope for merchants
- 15:44:04 [Ian]
- ..the PAN is sent to the gateway server from the browser or payment app
- 15:44:16 [Ian]
- ...in exchange it will get a token..merchant will only get a token
- 15:44:36 [Ian]
- ....network tokens replace PAN with dynamic PAN with cryptogram
- 15:44:57 [Ian]
- ...so the former is motivated by PCI scope, the latter by security
- 15:45:00 [Ian]
- https://github.com/w3c/webpayments-methods-tokenization/wiki
- 15:45:40 [Ian]
- q?
- 15:45:59 [Ian]
- Clinton: My role in EMVCo is chair of the tokenization WG
- 15:46:08 [Ian]
- ack mw
- 15:46:28 [Ian]
- mweksler: Thanks for the spreadsheet, Stan!
- 15:46:32 [Ian]
- ...great to be concrete.
- 15:46:52 [Ian]
- ..am I understanding the spreadsheet correctly...talking about payment app and the backend to which it connects
- 15:46:58 [Ian]
- ..is that the direction the spreadsheet was aimed at?
- 15:47:12 [Ian]
- Stan: I think the goal was mostly to look at the interaction of the clients in both situations
- 15:47:36 [Ian]
- ...this is browser and payment app
- 15:47:55 [Ian]
- mweksler: That requires find-tuning. E.g., I can take a picture of my credit card to add to Apple Pay
- 15:48:12 [Ian]
- ..there's a client that consumes the PAN and then somehow turns it into a token
- 15:48:12 [alyver]
- What you are describing is the provisioning of the card in the "wallet"
- 15:48:24 [Ian]
- ...we may need to add another column for "user agent" mechanism
- 15:48:32 [Ian]
- ....we may need to clarify what we mean by client
- 15:48:47 [Ian]
- Stan: I think that makes sense...the spreadsheet was focused on the client side library requirements
- 15:48:53 [Manash_MC]
- Manash_MC has joined #WPWG
- 15:49:02 [Manash_MC]
- +1
- 15:49:03 [ClintonA]
- q+
- 15:49:27 [Ian]
- ack Cli
- 15:50:04 [Ian]
- ClintonA: What you are highlighting here is associating a plastic card with a wallet is provisioning, which is decoupled from the transaction step
- 15:50:21 [Ian]
- mweksler: I think we still need to address them both (provisioning, usage)
- 15:50:44 [Ian]
- ...I think there is similarity in use, and deviation in provisioning
- 15:50:54 [Ian]
- manash: Tokenization, provisioning, transaction
- 15:52:25 [Ian]
- Stan: Gateway transactions are a representation of a card. They can be used or reused to create transactions.
- 15:52:47 [Ian]
- ...whether network tokens, due to their single-use flavor (mostly true but not always) mostly represent a transaction, though in some cases you can create subsequent charges using them
- 15:52:49 [ClintonA]
- q+
- 15:53:14 [Ian]
- ...Stripe creates a token, you can do a charge with the token and used for future charges
- 15:53:16 [alyver]
- q+
- 15:54:08 [Ian]
- ack clin
- 15:54:20 [Ian]
- IJ: I am hearing properties ... should we document?
- 15:54:36 [Ian]
- ClintonA: Gateway tokens are generally identified within an ecosystem (e.g., a braintree token is for that ecosystem)
- 15:54:43 [Ian]
- ..network tokens can be shared across multiple merchants/gateways
- 15:54:54 [Ian]
- ..which highlights another distinguishing quality - they can exist without a cryptogram
- 15:55:14 [Ian]
- ..when you introduce token+cryptogram creates a transactional combination
- 15:55:40 [Ian]
- ..within the gateway space, each token is unique to an ecosystem and may not be used in a transaction
- 15:55:51 [Ian]
- ...network protects transaction outside the acquiring space
- 15:56:16 [Ian]
- roy: While things like "publishable key" and "merchant id" sound similar, they are different values by gateway
- 15:56:20 [shift4sms]
- q+
- 15:56:37 [Ian]
- ...you don't get to reuse keys...which says to me each gateway might want its own PMI
- 15:56:39 [Ian]
- ack aly
- 15:56:58 [Ian]
- alyver: There was a comment earlier about gateway/network tokens behaving the same way once in the system...for network tokens there's a provisioning step
- 15:57:23 [Ian]
- ...at that point stored in my wallet...then when I do a transaction, the encrypted payload is returned to the merchant who decrypted
- 15:57:56 [Ian]
- ...in the case of a gateway token (I am thinking Android Pay / Chrome implementation of PR API).....gateway tokenization happens with downstream PSP and merchant gets back a gateway token
- 15:58:05 [Ian]
- ...I'm not sure if we are also considering that flow
- 15:58:14 [Ian]
- ack shif
- 15:58:20 [Ian]
- q+ mweksler
- 15:58:30 [stan]
- q+
- 15:58:46 [Ian]
- steve: Regarding reuse of gateway tokens...not sure you can lump them all together. Our gateway has 2 forms of tokens in our API process...
- 15:58:51 [Ian]
- ...whether single or multi use toikens
- 15:58:54 [Ian]
- s/toikens/tokens
- 15:59:07 [Ian]
- ...gateways can to multi-use tokens...not sure you can generalize the distinction
- 15:59:24 [Ian]
- ...to me the only really diff between the two is that a gateway token can't really be used in a wallet scenario
- 15:59:36 [Ian]
- ...not generally reusable
- 15:59:48 [Ian]
- ...other than that, the features can be mixed and matched
- 16:00:04 [Ian]
- mweksler: that's fair. Gateway tokens are "scoped" to the merchant that they were added under
- 16:00:19 [Manash_MC]
- Manash_MC has joined #WPWG
- 16:00:31 [Ian]
- ...if I add a card through a web site and I use stripe as a PSP, I get back a token that is scoped to that site and I can't use with another site even though I am same user, might be same PSP, etc.
- 16:00:36 [Ian]
- ...that is definitely a difference.
- 16:00:45 [ClintonA]
- +q
- 16:00:47 [Manash_MC]
- +1
- 16:00:58 [Ian]
- ...in terms of similarities, if we look at PR API, and say there is a tokenized payment handler
- 16:01:22 [oyiptong]
- q+ gateway tokens + wallets
- 16:01:26 [Ian]
- ...and we do some enrollment (let's put aside that for a moment), at that point, I get a token and payment handler is responsible for handing the right token back to the browser
- 16:01:37 [Ian]
- ..that was the seemingly appealing similarity between the two approaches
- 16:01:39 [Ian]
- ack mweksler
- 16:01:55 [Ian]
- ...it does feel appealing to me - you have the same interaction regardless of gateway or network token
- 16:01:56 [oyiptong]
- err, i messed up the queue, sorry, Ian
- 16:02:00 [Ian]
- q?
- 16:02:04 [Ian]
- ack stan
- 16:02:09 [Manash_MC]
- q+
- 16:02:18 [Ian]
- queue==ClintonA, oyiptong, Manash
- 16:02:46 [Ian]
- (Suggest columns: "encrypted?" "scoped?"
- 16:02:57 [Ian]
- stan: gateways have integrated with network tokenization solutions in many ways
- 16:03:11 [Ian]
- ..even if we were to layer the two systems one on another, it would probably not be compatible with thew ays
- 16:03:19 [Ian]
- ....that gateways get those tokens today
- 16:03:37 [Ian]
- ...and so it feels like even if we wanted to layer systems to get a unified tokenized API it would nonetheless create complexity
- 16:03:59 [Ian]
- ...we've been discussing internally at Stripe....current thinking is that it would be complex
- 16:04:26 [Ian]
- ...feels complex to abstract all tokenization aspects
- 16:04:37 [Ian]
- ....gateways expect network tokens today in non-standard ways
- 16:05:12 [Ian]
- q?
- 16:05:14 [Ian]
- ack Cli
- 16:05:32 [Ian]
- ClintonA: Some of the language that I hear now is that network tokens do not have a common way of requesting/receiving tokens
- 16:05:37 [Ian]
- ...that's helpful feedback for me
- 16:06:28 [Ian]
- ...one of the things I'd like to clarify: when we look at token types...I think the problem to solve is "if you have a wallet that needs to store a cardholder's credentials, if you use a gateway token, that wallet scope is limited to the gateway..but if you use a network token, can be reused independent of gateway"
- 16:06:42 [Ian]
- ...I hear the problem being how to reuse a token across merchants/acquirer
- 16:06:47 [shift4sms]
- q+
- 16:07:28 [shift4sms]
- q-
- 16:08:04 [Ian]
- ack oy
- 16:08:40 [Ian]
- oyiptong: Thanks for the spreadsheet. I'd like to touch on something Steve said...he was saying that network tokens be stored in a wallet but gateway tokens cannot...I don't think that's quite accurate. I think we could store gateway tokens by origin
- 16:09:01 [Ian]
- ...so while it's true that gateway tokens are scoped to PSP and merchant, but in a wallet you could store it for a specific (merchant) origin.
- 16:09:23 [shift4sms]
- +1
- 16:09:24 [Ian]
- ...for example, foo.com uses gateway token could be stored in my wallet specifically for Stripe+foo.com
- 16:09:51 [Ian]
- ...but it is true that we lose interop in the sense that "same PAN cannot be reused on another origin even if they use the same PSP"
- 16:10:21 [Ian]
- ...if we lived in a world where network tokens were the norm, we wouldn't need gateway tokens, but you'd still have the problem of storing token in wallet based on network used
- 16:10:22 [Ian]
- q?
- 16:10:25 [Ian]
- ack Ma
- 16:10:58 [Ian]
- Manash: From the merchant perspective (or whoever is invoking PR API)...if I am merchant or say worldpay...what is the difference in terms of options
- 16:11:10 [Ian]
- ....can that be standardized so that merchant does not have to create different options
- 16:11:14 [Ian]
- ...that is one thought
- 16:11:34 [Ian]
- ..the second is ... the response to the merchant...can that response be in a standard format independent of token type
- 16:13:08 [Ian]
- Stan: If we look at what the user wants - an easy way to do multi-gateway tokenization without needing a central vault
- 16:13:14 [Ian]
- ...that can be provided for outside of this effort
- 16:13:37 [Ian]
- ...an alternative is to address network tokenization clearly today
- 16:14:22 [Ian]
- mweksler: I want to mention a few things from our perspective...I am sure we agree we want to make it easy for users ...but from a merchant perspective, we already have the pipes that are mentioned in the spec (tokenizing things from the browser using PSPs)...but we need multiple integrations
- 16:14:26 [Ian]
- ...this standard would just be one of those
- 16:14:46 [Ian]
- ...network tokenization at the moment requires a lot of ceremony before it can be used..e.g., redirecting the user
- 16:14:50 [stan]
- q+
- 16:14:52 [Ian]
- ...a lot of steps are required
- 16:14:57 [Ian]
- ..but that means more friction
- 16:15:17 [Ian]
- ..I think that is perhaps the single most difficult aspect of the network tokenization schemes I've seen -- multiple steps to onboard a user.
- 16:15:26 [Ian]
- ..but in the end they result to something that is very similar to the gateway tokens
- 16:15:47 [ClintonA]
- +q
- 16:15:51 [Ian]
- ...the merchant wants to process something, it gives a token to its integrated PSPs and the transaction goes through.
- 16:16:13 [Ian]
- ..if we focus on that, and reduce the complexity stan refers to (and hide from users) we could come up with something easy to use and never requires merchants to see a PAN
- 16:16:14 [Ian]
- ack stan
- 16:16:31 [Ian]
- stan: I strongly agree on the goal of making using network tokenization easier with less integration for merchants
- 16:16:49 [Ian]
- ..but having one single client side integration is an orthogonal goal and we can sequence them
- 16:17:02 [Ian]
- ...could start with network and then build a layer on top to solve multiple merchant integrations
- 16:17:10 [Ian]
- ...trying to solve all in one go makes it easier
- 16:17:20 [Ian]
- mweksler: Why start with network tokenization over gateway?
- 16:17:51 [Ian]
- stan: they are 2 different beasts...one is user interaction in user agent that generates a token (that's network). Whereas gateway tokenization is a representation of a card.
- 16:18:13 [Ian]
- ...we can standardized the APIs for network tokenization (redirect based)...and once we get there, we can do gateway
- 16:18:19 [mweksler]
- q+
- 16:18:30 [Ian]
- ..there are also other payment methods (beyond cards) to look at
- 16:18:52 [Ian]
- ...I think focusing on network tokens will reduce the problem space and then we can sequence...that's our current take
- 16:19:00 [Ian]
- ..I am hearing other takes as well
- 16:19:02 [Ian]
- ack Cl
- 16:19:53 [Ian]
- ClintonA: I think that choosing gateway v. network is likely to be the wrong approach. I think that both types provide value. I think network tokens provide value where gateway tokens cannot ... security features outside of acquirer
- 16:20:05 [Ian]
- ...I think layering the systems on one another would be helpful
- 16:20:15 [Ian]
- ...but there are complexities
- 16:20:17 [Ian]
- ack mweksler
- 16:20:31 [Ian]
- mweksler: I wanted to take the two previous points and wrap them into the larger context of the other specs in play
- 16:20:46 [Ian]
- ...by the way, I'd love to get a spec around network tokens; I agree it's a good idea...
- 16:21:01 [Ian]
- ..but I think one of the reasons we started to look at gateway tokens has to do with the current state of the specs
- 16:21:10 [Ian]
- ...Basic Card has PANs flowing freely between browser and merchant
- 16:21:51 [Ian]
- ...a few of us felt that Basic Card was a reasonable way to start, but we need to fast forward to increasing security, does not expose merchant to PCI Scope
- 16:21:59 [shift4sms]
- q+
- 16:22:03 [Ian]
- ..so an idea was "encrypt in the browser" and flow through existing channels
- 16:22:04 [Ian]
- q+
- 16:22:24 [Ian]
- mweksler: one way to look at sequencing is that gateway tokens seem to provide an easier next step
- 16:22:39 [Ian]
- Roy: I am hearing a lot of comments around network tokenization v. gateway..if you look at the current draft spec
- 16:22:46 [Ian]
- ..it is very network-token oriented
- 16:22:59 [Ian]
- ...maybe we can take the learnings from today and see how relates to existing text
- 16:23:03 [Manash_MC]
- +q
- 16:23:13 [Ian]
- ...specifically around gateway tokens, does it make sense to look at a spec around gateway tokens?
- 16:23:15 [Ian]
- ack shif
- 16:23:56 [Ian]
- shift4sms: A lot of the discussion seems to be pulling some of the feature set of gateway and merging with some of the feature set of networks. A lot of features cross over...but network tokens for a majority of their usage today is single-use (there are exceptions)
- 16:24:03 [ClintonA]
- +q
- 16:24:06 [Ian]
- ...the gateway tokens are typically more for multi-use
- 16:24:40 [Ian]
- ...we are talking about "merging" but keep in mind that once you start to make a gateway more reusable across merchants, you need to make sure we are not merely replacing sensitive information with more sensitive informaiton
- 16:24:47 [Ian]
- ack me
- 16:27:39 [Ian]
- IJ: Should we have parallel activities to see how similar the two approaches look in practice?
- 16:27:44 [mweksler]
- +1 on articulating as two parallel proposals
- 16:27:48 [ClintonA]
- q-
- 16:27:56 [Ian]
- Manash: I think we may need additional merchants to hear their needs
- 16:28:34 [Ian]
- ...EMVCo has worked hard to create a token format that works across a lot of stakeholders and we should leverage that
- 16:29:02 [Ian]
- ...we should probably get input from merchants (even outside of W3C) and get their feedback on the two tokenization approach
- 16:29:03 [Ian]
- q?
- 16:29:05 [Ian]
- ack Man
- 16:30:13 [mweksler]
- happy to help Stan
- 16:30:27 [Ian]
- ACTION: Stan will take another pass on the spreadsheet to shed light on categories / similarities
- 16:30:27 [trackbot]
- Error finding 'Stan'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
- 16:31:34 [Ian]
- IJ: Are parallel efforts responsive to Stripe perspectie?
- 16:32:06 [Ian]
- Stan: Taking our understanding, simplifying network tokenization was for us "most urgent and efficient"
- 16:32:13 [Ian]
- ...so that aligns with current state of spec
- 16:32:43 [oyiptong]
- q+
- 16:33:12 [Ian]
- IJ: Any interest for Airbnb + MasterCard to attack gateway spec?
- 16:33:15 [Ian]
- ack oyiptong
- 16:33:23 [Ian]
- oyiptong: It might be good to think about Airbnb to work on both
- 16:33:56 [Ian]
- ....if stan's right and network is an easier way to start....worth it for us to think about both
- 16:34:06 [Ian]
- ...or michel on network and me on gateway
- 16:34:17 [Ian]
- Manash: I can work with folks on gateway tokens as well
- 16:34:58 [alyver]
- I'm happy to participate in the network token discussion.
- 16:36:52 [Ian]
- IJ: Roy are you still lead on the network side?
- 16:37:17 [Ian]
- Roy: yes
- 16:37:25 [oyiptong]
- +1
- 16:37:56 [Ian]
- IJ: Olivier and Manash work out who takes lead for gateway
- 16:38:09 [Ian]
- Manash: I think we should organize a demo of how network tokens work
- 16:38:37 [Ian]
- IJ: Any update on updated flow diagram?
- 16:38:46 [Ian]
- Manash: I will check
- 16:38:46 [Ian]
- Topic: next meeting
- 16:38:56 [ClintonA]
- q+
- 16:38:59 [Ian]
- ack clin
- 16:39:27 [Ian]
- ClintonA: As you pointed out, I am hear with Amex affiliations but also participate in EMV in tokenization, remote commerce
- 16:39:31 [Ian]
- ..happy to be part of conversations
- 16:40:15 [Ian]
- Next meeting: 6 June
- 16:40:18 [mweksler]
- +1
- 16:40:18 [oyiptong]
- +1
- 16:40:27 [Ian]
- ...and in the meantime we will work to advance the gateway story
- 16:40:43 [Ian]
- RRSAGent, make minutes
- 16:40:43 [RRSAgent]
- I have made the request to generate http://www.w3.org/2017/05/23-wpwg-minutes.html Ian
- 16:40:48 [Ian]
- RRSAGent, set logs public
- 16:47:53 [Ian]
- RRSAGent, make minutes
- 16:47:53 [RRSAgent]
- I have made the request to generate http://www.w3.org/2017/05/23-wpwg-minutes.html Ian
- 16:47:56 [Ian]
- RRSAGent, set logs public
- 17:03:40 [betehess]
- betehess has joined #wpwg
- 17:05:14 [cweiss]
- cweiss has joined #wpwg
- 17:49:34 [cweiss]
- cweiss has joined #wpwg
- 17:55:34 [cweiss]
- cweiss has joined #wpwg
- 18:03:58 [stan]
- stan has joined #wpwg
- 18:04:20 [alyver]
- alyver has joined #wpwg
- 18:15:12 [alyver]
- alyver has joined #wpwg
- 18:19:23 [stan]
- stan has joined #wpwg
- 18:28:25 [stan]
- stan has joined #wpwg
- 18:53:15 [betehess]
- betehess has joined #wpwg
- 19:07:36 [cweiss]
- cweiss has joined #wpwg
- 19:13:51 [cweiss]
- cweiss has joined #wpwg
- 19:15:21 [Zakim]
- Zakim has left #wpwg
- 20:16:07 [stan]
- stan has joined #wpwg
- 20:47:14 [cweiss]
- cweiss has joined #wpwg
- 21:25:06 [stan]
- stan has joined #wpwg
- 21:29:36 [stan]
- stan has joined #wpwg
- 22:06:58 [cweiss]
- cweiss has joined #wpwg
- 22:24:27 [stan]
- stan has joined #wpwg
- 22:56:26 [cweiss]
- cweiss has joined #wpwg
- 23:03:59 [stan]
- stan has joined #wpwg
- 23:07:56 [stan]
- stan has joined #wpwg
- 23:12:10 [stan]
- stan has joined #wpwg
- 23:33:56 [stan]
- stan has joined #wpwg
- 23:40:25 [stan]
- stan has joined #wpwg
- 23:43:58 [stan]
- stan has joined #wpwg
- 23:54:08 [stan]
- stan has joined #wpwg
- 23:55:47 [cweiss]
- cweiss has joined #wpwg