Manu Sporny: Any updates to agenda? ✪

Manu Sporny: We went over the IGF workshop on yesterday's Credentials CG call, so let's just refer to that discussion. ✪

Manu Sporny: Here's the transcript from the Web Payments/Credentials workshop at IGF 2014: http://www.intgovforum.org/cms/174-igf-2014/transcripts/2059-2014-09-04-ws69-payment-privacy-policing-paradox-room-4 ✪

Manu Sporny: Here's the video from the workshop: https://www.youtube.com/watch?v=m8cIYzy5MIA ✪

Manu Sporny: We'll put together a page with that info so when talking to governments, standards orgs, etc. we can point to the page. ✪

Manu Sporny: We discussed this stuff on the Credentials CG call yesterday, so we won't rehash that discussion here: http://opencreds.org/minutes/2014-09-09/#5 ✪

Manu Sporny: There's the in depth talk about the workshop (link above). ✪

Manu Sporny: We'll do followup and try to get those people into the work. ✪

Manu Sporny: Wallet / Payment Initiation use cases: https://www.w3.org/community/webpayments/wiki/UseCases ✪

Manu Sporny: Last time we talked about this one - Use Case: A merchant advertises different details, such as price, for an offer of sale based on potential payment processor choice. ✪

Manu Sporny: We ended on Michael Williams' comments, basically saying that we don't think we can achieve what he wants, even though we really want to. [scribe assist by David I. Lehn] ✪

Dave Longley: We've had discussions about this in the past, the ability to do decentralized clearing. Ripple is an option. We've also talked about using a more decentralized version of the block chain technology. The key issue is that we need some way to "validate" monetary inputs into the system. [scribe assist by David I. Lehn] ✪

Manu Sporny: This is all experimental technology, that's the problem. We don't have enough experience w/ it to think about standardizing it because we're not sure it scales. [scribe assist by David I. Lehn] ✪

Timothy Holborn: A project is emerging entitled bitmark https://github.com/project-bitmark/documents/tree/master/pdf perhaps we could ask them whether some technology might exist as to provide that type of service. ✪

Timothy Holborn: I'm not sure if the way bitmark is implemented supports that or if it can be effectively forked to achieve the needs of web payments ✪

Timothy Holborn: In melvin's web credits system he has a decentralized blockchain that was working off of data.fm. I believe it was. ✪

Timothy Holborn: http://webcredits.data.fm/ ✪

Timothy Holborn: Is it closer to http://dig.csail.mit.edu/2010/Papers/IAB-privacy/httpa.pdf ?? ✪

Manu Sporny: I don't think it was a decentralized block chain, you could put it anywhere, but you couldn't fork the block chain, the fundamental design we're talking about is different from centralized block chain stuff, his stuff would allow you to put the block chain somewhere on the web and everyone would have to agree to a particular history, it was each account gets its own block chain ✪

Timothy Holborn: Would this be helped if there was some sort of credentialing system? ✪

Manu Sporny: There's certainly a creds part to it, the URL/HTTP part is used for looking up where a particular resource is, the thing we've been vacillating between is using URL or some decentralized/dht system like telehash to create those URLs. ✪

Manu Sporny: Using URLs only as an entry point into the decentralized credential/block chain to do reading/writing ✪

Manu Sporny: We have all these techs up in the air, if we want to make quick progress we can't make the decision to standardize telehash or some decentralized mechanism, we have to use techs that already exist, URLs, JSON-LD, IC, etc. ✪

Timothy Holborn: It sounds like it's in an experimental field, it's something we're interested in but we don't want to steer away from critical path, it's where innovation can happen and we can participate in some way ✪

Manu Sporny: I agree, that's the response to Michael we want to have, we agree with him, we want to do what he's talking about but we need the tech to get there. ✪

Manu Sporny: He even pointed to the decentralized settlement process we have in one of our specs, but he probably doesn't know that's really experimental, we just haven't had the time to work on it ✪

Timothy Holborn: I think bitmark has 20 active devs on the project, i've spoken to Mark, and he's shown interest in web payments ✪

Timothy Holborn: They may be interested in participating in the CG ✪

Timothy Holborn: Maybe we can get them involved w/o having them be a constituent of our critical path ✪

Manu Sporny: Yes, sounds great, i say that having no real view into technical details of bitmark yet, but if you think it would be good to look at, bring them in ✪

Manu Sporny: Jorge is saying he doesn't know if a website could display a proper price. The problem is that since the person hasn't specified who their payment processor is, on the website, the website has no way of running the code for showing them the actual price. ✪

Manu Sporny: We could have some kind of API in the browser for dealing with multiple offers ✪

Dave Longley: Right now, the merchant can enumerate different offers. The merchant can figure out how to display it. [scribe assist by Manu Sporny] ✪

Timothy Holborn: Description of Bitmark: https://twitter.com/ProjectBitmark/media ✪

Timothy Holborn: In images. ✪

Manu Sporny: Anything else on the use case before moving on? ✪

Timothy Holborn: Nope ✪

Manu Sporny: Next use case - Use Case: A buyer can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits. ✪

Manu Sporny: Steven Rowat said - I think these could wait until a later version. I know many marketing strategies use them, but many don't; essentially they're an optional add-on (IMO there's an argument that they're like tariff barriers -- somebody starts, then everybody does it, and it becomes cruft that we all pay for without good reason). I suggest putting minimal resources into it, as a socket that the vendor must provide most of the code/structure for. ✪

Manu Sporny: What we could do is push this off to the creds group ... having a loyalty coupon/membership is like having a credential ✪

Timothy Holborn: +1 ✪

Manu Sporny: When you try to do a purchase a vendor could optionally ask for a loyalty credential ✪

Manu Sporny: And then the vendor could price accordingly ✪

Manu Sporny: Adrian also said that he'd prefer to have this for later iterations. ✪

Timothy Holborn: I agree, i would just ask if that credential could be used to provide the discount in the transactional process ✪

Manu Sporny: The way it would work, i think with the current tech, there would be a request for the loyalty card, then the website would show a different set of offers ✪

Dave Longley: We can certainly do it the way that you just suggested. I can't think of a hook that a payment processor could use to process that. [scribe assist by Manu Sporny] ✪

Dave Longley: Payment processor looking at a set of payees, this other information is present (like a loyalty coupon), it's not built into the transaction process. The merchant probably establishes that you have the loyalty card through the credentials process. [scribe assist by Manu Sporny] ✪

Timothy Holborn: This doesn't affect the digital receipt, right? [scribe assist by Manu Sporny] ✪

Dave Longley: The vendor can always include extra information in the digital receipt, to say that they used a loyalty card, but the payment processor will not know about that information (most likely) [scribe assist by Manu Sporny] ✪

Dave Longley: There would be no special processing rules that the payment processor could apply to the loyalty card info, but the vendor could include it and get that information back in the receipt ✪

Dave Longley: (It would be opaque to the payment processor) ✪

Dave Longley: In the future, if a certain token is present in an offer, then a different set of payees could be used. If we think it's beneficial to be put into the transaction process. [scribe assist by Manu Sporny] ✪

Dave Longley: There will be some details about ensuring that the information remains private - loyalty cards can't be misused. [scribe assist by Manu Sporny] ✪

Timothy Holborn: I think there is a use case to have a social membership card ✪

Timothy Holborn: And that's also a credentials problem ✪

Manu Sporny: Yeah, i think whenever we're talking about membership i think that's a credentials thing that we can push off to that group ✪

Manu Sporny: Until there's a very solid use case that says this loyalty coupon/membership card absolutely must be part of the txn process we should leave it out and let people just compose the two techs: creds and payments together to solve these complex use cases ✪

Manu Sporny: Rather than complicating the payment protocol ✪

Manu Sporny: Next use case is - Use Case: Leveraging variable degrees of anonymity per requirements of the payment transaction. ✪

Manu Sporny: Feedback from Adrian is to shift this to a later version. ✪

Manu Sporny: Based on the discussions we've been having, especially about the nigerian ID card, kingsley and steven rowat's input on that, i don't think that the variable degrees of anonymity and privacy we can shift this to a later version ... people seem to be rightly concerned about this issue ✪

Timothy Holborn: Is this a creds use case? ✪

Manu Sporny: Kind of, if you have an account that is identified by some URL and that URL can be used to discover who you are and get some info about you, then that's problematic, without even talking about the creds stuff, but if your URL has "timholborn" in it then people can identify who you are, or based on your spending habits at two sites owned by the same org, if you transmit a pseudo-anonymous cred and you name/whatever is in the account URL then your ID is less than you think. ✪

Manu Sporny: You shouldn't have to transmit your entire ID if you're just buying a candy bar ✪

Timothy Holborn: I absolutely agree i just thought creds would be handling this? ✪

Manu Sporny: It could be, there are two chunks of info transmitting to the website, you notify the website who your payment processor is (and that's it) and they don't know who you are, if when the digital receipt is generated and the payment processor puts in there, say your name in a URL, then your privacy is violated because the payment processor didn't know you were doing something pseudo anonymous ✪

Manu Sporny: And so that info gets accidentally leaked. ✪

Timothy Holborn: Makes sense, I agree. ✪

Timothy Holborn: I think the language should be clearer -- defining pseudo-anonymity, etc. ✪

Manu Sporny: I think that we should use pseudo-anonymity everywhere ✪

Timothy Holborn: Yes, you said the tech isn't there for true anonymity ✪

Timothy Holborn: I think we should state some defs for anonymity ✪

Manu Sporny: I think there's a lot of confusion on what anonymity means, using cash isn't anonymous, serial numbers on cash, etc. ✪

Timothy Holborn: Video cameras in the building ✪

Dave Longley: Merchant saw your face ✪

Manu Sporny: When we talk about true anonymity it's something like a usb drop cemented into an alleyway w/ no cameras for multiple blocks around. ✪

Manu Sporny: We need to be more clear and use pseudo-anonymity from here on out so people don't think they are more protected than they are ✪

Manu Sporny: Whatever your definition of anonymity is, you may not be as private/safe as you are ✪

Manu Sporny: If you're that worried about it you shouldn't be doing it over the internet ✪

Manu Sporny: The internet makes it easy to find "the" node to send information to... and then it's easy to track that particular node ✪

Timothy Holborn: I believe lay technical people believe things like 'Bitcoin provides true anonymity' and that's misleading and unfortunate, from a marketing level it's difficult to clarify, between one org that claims anonymity and one that claims pseudo-anonymity, i think integrity of this process is of utmost importance. ✪

Manu Sporny: We're not against true anonymity per se but it would be completely incorrect to say we provide it ✪

Timothy Holborn: I'm a citizen of Australia and if i'm being investigated that much then so be it. I think people that are super afraid of that maybe shouldn't be on the Web. ✪

Evgeny Vinogradov: Maybe we can achieve true anonymity in this use case, the buyer can be completely anonymous to merchant but provide details to merchant. ✪

Timothy Holborn: What i was saying, was that as a subject to the rule of law (of my country, Australia) then if lawful intercept makes requests - so be it. Yet, there are so very many use-cases where people have the right to pseudo-anonymity. ✪

Dave Longley: We should still be careful about using "true anonymity". It's just a higher degree of anonymity. If a merchant uses sophisticated tracking techniques, the buyer could be tracked. [scribe assist by Manu Sporny] ✪

Timothy Holborn: Almost every other party; save, local law-enforcement, etc. ✪

Manu Sporny: For example, putting a Google tracking cookie would allow Google to figure out who a buyers is. ✪

Manu Sporny: Any kind of tracking cookie from any org or conglomerate could allow them to follow browsing habits and figure out who a person is ✪

Timothy Holborn: Or a browser login, etc. ✪

Manu Sporny: There are so many different ways to track people online, while we can solve the pseudo-anonymity problem between buyer and merchant ... that doesn't mean cookie tracking, malware, etc. lots of other devices don't exist that errode your privacy online (all out of scope for the work here) ✪

Manu Sporny: We're just trying to increase the level of effort any org would have to extend to violate your privacy, we're not saying it's impossible just making it as difficult as we can to break privacy ✪

Timothy Holborn: The gov't is of service to the people, and what they provide is very different from what a private corporation ✪

Manu Sporny: This is the next one - Use Case: A buyer discovers an offer for sale by a merchant under terms that the merchant is comfortable with. The offer includes a list of payment processors that the merchant is capable of receiving payment through. The buyer's software contacts a subset of those payment processors that they are capable of sending payment through to get finalized transaction details (such as price or speed) before executing the most desirable transaction. ✪

Manu Sporny: Jorge's feedback - NASCAR problem ✪

Dave Longley: Again, I think that's a misunderstanding of the NASCAR problem. This is about user choice, not about splattering choices that are not relevant to the buyer. This is about giving the buyer choice. This is about providing the buyer with utility, not noise. [scribe assist by Manu Sporny] ✪

Manu Sporny: Feedback from Michael Williams: Is there a user flow for proxying from payment processors included by merchant to another payment processor as described above? ✪

Dave Longley: We should at least mention the decentralized payment processor/proxied payment processor idea as a design criteria for a future version or similar so it's on the IG's radar ✪

Manu Sporny: Next Use Case: A buyer uses a native non-browser application on their mobile phone or tablet, or a web browser to make a purchase at an app store. ✪

Manu Sporny: Jorge's feedback: Native apps are ok as long as they use the Web infrastructure for the transactions (e.g. REST APIs) ✪

Timothy Holborn: +1 ✪

Dave Longley: +1 ✪

Manu Sporny: Anything else to discuss before next call? ✪

Timothy Holborn: The creds group is working on some of the use cases for identity, if there's any feedback from web payments group that would be great ✪

Timothy Holborn: Any other use cases they suggest, etc. ✪

Manu Sporny: I think we have to be very careful with how we reword the use cases in the creds group, some will be fundamental for creds and others will be periphery use cases web payments people care about ✪