Digital Offers Community Group

<scribe> Scribe: Ian

<adam> I am not sure I am getting the invites, or I don't know where I am supposed to be getting the access number and code. Can someone please post them?

<dezell> https://global.gotomeeting.com/join/389946949 Access Code: 389-946-949

Adam, I believe you are subscribed to public-digitaloffers@w3.org

<dezell> Phone: United States +1 (571) 317-3116 Access code above

https://lists.w3.org/Archives/Public/public-digitaloffers/2017Feb/0012.html

Review of discussion topics

https://www.w3.org/community/digitaloffers/wiki/Discussion_Topics#New_Discussion_Points_and_Use_Cases

<manu> Ian: We have a few people here, we may not want to approve, just organize on the call today. Maybe we can get feedback via email list.

<Zakim> manu, you wanted to request small discussion around topics/priority/presentation?

manu: It sounds good to me. I don't think we need formal approval
... we could put the list before people and see which ones people support
... more input we can get before the FTF the better
... but I'm ok at the FTF meeting to ask for a show of hands of people to push for things they want to advance
... we also need to avoid everyone easily raising their hand so we may wish to ask for time commitments as part of advancing a topic

public-digitaloffers@w3.org

dezell: 4.2 and 4.4 are click-through use cases that don't seem to affect the payment system

<manu> Ian: The reason I like 4.2 - merchant website - click to store is an interesting thing.

<manu> Ian: If overall, one plausible set of activities is to make it easier for things to get into payment apps, then this is something that's interesting to get into that view. After a transaction, what do we need to get a digital receipt into someone's payment app?

<manu> Ian: The current way that browsers talk to payment apps is being designed in the payment apps task force. That's how communication will take place. We haven't said anything about how people do other things to talk to payment apps. That communication between browser and payment app is an interesting area to look at.

<manu> Ian: For 4.2.5, that feels like the same thing - same problem from a protocol perspective.

dezell: It's almost like click through is acceptance of offer; maybe that needs to be made clear

manu: Going back to what Ian was saying about how to get information into payment apps (coupons, digital receipts)
... I think that's one of these things that these groups are dancing around

IJ: I am not talking about a general protocol; I want to talk about specific use cases

Manu: But multiple groups will be doing similar things - storing data, retrieving data
... we've seen that happen in verifiable claims
... it's fine, maybe we need to go through the exercise but the more of these things we do, the more the harder it will be to run these groups in parallel

<Zakim> manu, you wanted to note "how browsers talk to payment apps" and verifiable claims.

manu: I don't want us to only define this for payment apps
... we are talking about a digital receipt protocol for the web
... I think this conversation will play out over the next few years

<dezell> Ian: a risk of generalization is that browser vendors don't want to talk about open-ended things.

<manu> Ian: i think one of the problems is when we talk about open ended things, the browser vendors push back.

<manu> Ian: The use cases are not generalize store/retrieve things, it's specific to digital offers.

<manu> Ian: The way payment app stuff is happening, we are calling the thing the "payment app" ... but it may be more general than that.

<manu> Ian: Maybe we're listening to coupon acceptance events, maybe anyone can listen to those events.

<manu> Ian: Maybe we just listen to events, not caring about data in the pipe, we care about the hook for people to sign up for those things.

<manu> Ian: We have to talk about what that means - does list of available payment apps show up? That's where it becomes an interesting conversation...

<Zakim> manu, you wanted to note that that is exactly my point.

<manu> Ian: This is why click to save is interesting - but I would hesitate to overgeneralize before we actually consider the use cases in detail. Given enough of these things, it might emerge that there is a general thing to do, but I don't think we'll be able to go general in advance.

dezell: Regarding 'Later in the day, Annie is reviewing her newsfeed on Facebook when a targeted advert is shown on her page, which offers Annie a 15% discount on any camera within the manufacturer's range. Annie clicks on the ad, which takes her to the main retailer/manufacturer site and Annie commits to a purchase using the discount. "

This is "implicit" acceptance of offer

<dezell> Suggested revision: Annie is reviewing her newsfeed on Facebook when a targeted advert is shown on her page, which offers Annie a 15% discount on any camera within the manufacturer's range. Annie clicks on the ad, which takes her to the main retailer/manufacturer site and Annie adds the offer to her digital wallet.

Manu: I agree with Ian. I don't think we can generalize first. But I think we are going to end up in a generalized case; but without saying we need to take a generalized API
... I am concerned we will create too many specialized APIs in the browser

<manu> Ian: There are generalizable parts of the Web Platform - local storage, sessions storage, service workers, etc.

<adam> q

<manu> Ian: How they register for event is standard, how they store stuff is up to them, how they give data back to browser via promises is standard. We're just inventing specific data that use case paid for. I don't see anyone motivated w/ APIs are general things - getData/returnData - when you need specific data, you need to say what defaults are, how errors are handled, you end up with specific APIs for specific things.

adam: I think I hear what David is saying; it's mostly about how people get to a site...could we change this one to "on her social media feed she downloads the offer"

<manu> +1 feels more compelling / more direct.

adam: that might be more compelling and more direct

<dezell> +1 to either

dezell: That's fine. I had provided an alternative....I think getting the offer directly from the feed is also fine
... I'd like Kylie to agree to these changes
... I also think SMS receive offer is ok but firs tone on sign-up raises questions for me
... I suggest not approving those 2 yet

David: I would like user experience of "Not copyable" to be clearer

<Zakim> manu, you wanted to note there is no need to copy digital offers? Maybe "forward offer"?

Manu: This is a share use case. The actual use case is whether someone can share it with someone else

Ian: this seems to me to be more about redemption than distribution.

ltoth: Can we control distribution?

<manu> Ian: What does "can't be copied" mean? Like download a movie, but can't view it.

<manu> Ian: I don't think we want to get into locking down people's systems.

<Zakim> dezell, you wanted to recommend "shareable" and "not shareable"

<manu> Linda: Not enough people to make a decision today.

dezell: I think the name her is problematic

<Zakim> manu, you wanted to ask about "easy sharing"?

manu: I think we have redemption covered. So we should strike it here if it's only about redemption
... but if the use case may be more about "is it easy to spread information virally; for people to get valid copies"
... what to distributors embed so that it's possible to share and have a coupon still be valid?

dezell: Regarding age distinctions, the store does the check. The brick and more case is important
... it sounds from the way it's written that the age restriction is not actually part of the offer

ltoth: This ties into distribution (age restriction)...in the distribution case, age-restricted offers should not be shareable

dezell: merchants don't want offers to get into hands of ineligible (especially underage) people due to liability

<scribe> ACTION: DavidE to send back text suggestions to the CG (and getting response) [recorded in http://www.w3.org/2017/02/27-digitaloffers-minutes.html#action01]

Face-to-face meeting

manu: Question is about what to do with the presentation

<manu> Web-based Digital Wallets: bhttps://docs.google.com/presentation/d/1A0Kv1A66eTw4_YMXjLXT-RQR0WDLwlqoiL_meoX1Jt8/edit#slide=id.p

<manu> + an additional demo

<Zakim> manu, you wanted to ask ltoth for 5 minutes at the end to discuss digital offers presentation.

<manu> Ian: Looking forward to the demo, had discussed that w/ everyone here - that's a good use of 25 minutes. On the other hand, I don't think we should do the presentation at the face-to-face meeting.

<manu> Ian: They can see the background information, rationale, in the end, the question is - what use case should be surfaced that can fit in like the other use cases we have.

<manu> Ian: You can then tell people about why this use case is important, but some of that data is not specific to this use case, some of it is about value of coupons. Value of digital coupons wrt. printed.

<manu> Ian: If anyone asks why we're having a digital offers discussion, they can look at the data... let's focus on specific use case here.

dezell: I kind of understand that. I think the presentation magnifies the demo. What I think we should probably do is provide a link to the presentation
... I think focusing on the use case here is probably a good idea

<manu> Ian: The reason I don't want to do that is that we've already done that - we've done it in the past, we've done it in the task force. There is a digital offers CG - I don't think it's worth going back up to a high level, because people know that it's important.

<manu> Ian: I'd like to talk about Slide 17 - give us a reason to talk about those items... maybe review / prioritize use cases and early attempt at capabilities.

<manu> Ian: What are the other capabilities given our prioritized use cases?

IJ: I suggest organizing the 2 hours as:

1) Introduction of use cases

2) Prioritize use caess

3) Manu demo, highlighting missing capabilities

4) More capability discussion

<manu> Ian: Let's talk about retail use case as one of the use cases...

<manu> Ian: Then go into more detail, the flow more specifically, then show demo, then missing capabilities.

<manu> Ian: All marketing research, don't need it in presentation, but send the deck to the group.

<manu> Ian: It'll be helpful for others in the group to see how we get to the next step.

Manu: Actions are:

a) Update the wiki if use case not yet there

b) create a demo-specific deck focusing on slides 3, 4, demo, 17

Next meeting

13 March, noon ET

<manu> Ian: We haven't gotten a thorough discussion on use cases, we're adapting to that.

<manu> Ian: We can't go in and say that there is strong consensus on use cases - preliminary work we've done - use face to face meeting to get more eyes on it.

<manu> Ian: We can take all the things in there that are called use cases, and put them in one document, and then ask everyone to read it because we'll prioritize at the meeting.

<manu> Ian: At the end, we can put a chart up on the wall and write whether they want to do... or print it out, put check by every one they care about... maybe we can do 5 votes.

<manu> one red dot, two yellow dots, three green dots.

Manu: In version I am thinking of, colors have semantics

<manu> +1 to Linda

<manu> yes, that - very useful to get people up and moving and voting.

<scribe> ACTION: Ian to create a nicely formatted set of use cases with short labels [recorded in http://www.w3.org/2017/02/27-digitaloffers-minutes.html#action02]