See also: IRC log
<scribe> Scribe: Ian
Manu: We are currently
brainstorming around use caess
... at some point we'll need to organize into material that
communicates clearly to people not in this group
... for those people new to this, i wanted to show people an
example of where we might go
<manu> Digital offers CG Use Cases: https://docs.google.com/document/d/1lHgKql-M7bqmf4AGSJwsUaDaDCW22SaB-cEkdkSRI_U/edit#
See also WPIG use cases => https://www.w3.org/TR/web-payments-use-cases/
scribe: we define roles, needs, and tasks/requirements
Manu: We may need more market
verticals
... or highlights some market verticals with specific needs
ltoth: So we would migrate materials from wiki to this structure?
Manu: Yes, changing as needed
dezell: We may need to identify financial service providers
(or PSPs as we call them, but FSP is broader)
<manu> Ian: It's difficult to jump to requirements after use cases...
<manu> Ian: I can see using a formalism of roles to communicate use cases clearly and structure them, I don't have confidence that we'll get to requirement level in the IG.
<manu> Ian: If people start to write down specs, we may be able to get to requirements, I don't expect to have requirements in early stages.
<Zakim> manu, you wanted to discuss requirements.
Manu: Agree with Ian that
requirements are too soon for digital offers.
... agree that we need specs first before getting to the level
of requirements (e.g., as we have done with payments or
verifiable claims)
... the thing we are trying to do here is to create space in
the document for when we get to them
... agree that roles and needs are high level, and requirements
are low level and we would not get to them for at least a
couple of months
<Zakim> dezell, you wanted to clarify whether roles are in/out
<Zakim> manu, you wanted to note that there are /some/ requirements that are easy to note...
Manu: The other way to look at this, is that there may be some requirements that are important requirements for people in the group
<SJS> Isqq+
Manu: therefore saying something like "must interoperate for issuance, storage, and retrieval"
<manu> Ian: What we may want to do is write down things we want in a charter. Like interoperability. There must be interoperability for issue, storage, and retrieval - it would help us keep in mind that there are specific actions on these things that are desirable.
<manu> Ian: Rather than frame them as technology requirements, that end up being articulated as a future WG. It might be better to focus those as Charter Requirements.
<manu> Ian: If we put stuff in the charter as aspirational, they can push back on it being too broad.
<manu> manu: Agree that doing that is useful.
<SJS> q
<AdamLake> q
<manu> ltoth: I find the document useful.
<manu> dezell: I think it's useful
<manu> SJS: Useful because it brings all the use cases together.
IJ: No objection to people trying to create a useful document; I am not ready today to adopt anything formally moving forward
<manu> https://www.w3.org/Payments/IG/wiki/Vision2017#Web-based_Digital_Wallets.2C_Loyalty.2C_and_Payments
Manu: Digital Bazaar put forth a
proposal ... it tries to tie together a set of w3c
activiteis
... payments, verifiable claims, digital offers
... Ian raised a question whether that discussion on web-based
digital wallets and loyalty should shift to the digital offers
cg
<manu> Ian: One way to proceed may be for Digital Offers to do some work and you bring that experience back to the relevant group. For example, payment app that makes payments and apply coupons during checkout... we used PaymentRequest, and Verifiable Claims to do it, plus ARTS, and come back and say "we couldn't do it because of X, or Y".
<manu> Ian: That seems to be very valuable information - web stack as its evolving does/doesn't allow us to do this. Implementation experience with things that are emerging. The premise is that Verifiable Claims could be used to do digital offers.
<manu> Ian: If we want to be able to do digital offer redemption through checkout, and we could do everything through Verifiable Claims and PaymentRequest, then that would be a solved problem. Or we couldn't do it because that bit is missing.
<manu> dezell: I think we spend a bit of time in the WPIG waiting to hear feedback from other groups, and that's okay.
dezell: Seems like digital offers CG should be thinking about wallets
manu: I liked Ian's
characterization of it ... it gives us a clear path to
proceed.
... I think digital wallets will touch on various pieces of w3c
work (payments, identity, digital offers)
... it may be that the digital offers CG is not the right place
for a broader wallet discussion
... as Ian said, best way to help tie things together is to try
to implement various pieces
... and see what the limitations are
<manu> Ian: There is other experience with this sort of thing, implementing some PaymentRequest/payment app API with interledger. Payment App making payments across ledgers using Interledger.
<manu> Ian: There will be experimentation to try to put these pieces together and that will feed back into W3C.
<manu> Ian: I'm not yet convinced that there is a "project" that is as high-level as digital wallets. Digital Wallets are a thing that people feel can help improve security/convenience, and yet it doesn't feel like W3C should be out to do digital wallets.
<manu> Ian: Software could be digital wallet, or it could be something else. Is Digital Wallet a compelling thing to focus on, or capability usage, which is what we're going for. It feels easier to focus on concrete thing - redeem coupons at checkout. it turns out that that's a thing that people want to use digital wallets for.
<Zakim> manu, you wanted to note not "out to do digital wallets", just to ensure the stuff they're building fits together.
<manu> Ian: What do we need to use on the Web to make that happen? Are digital wallets a side-effect? digital wallets are just software, not a capability of the Web.
manu: Now I think I see where the
disconnect is.
... I agreee that the focus should be on the capabilities
... the suggestion was not to create a digital wallets CG or
WG...
... rather, the term digital wallet is used as a term that is
an umbrella
... but I agree that we should be focused on capabilities to
address specific tasks.
... e.g., you are issued a loyalty card...you get
messaged...you use it to make a payment
... so digital wallet may be the wrong term, but the point is
to have capabilities that enable things to work seamlessly.
<Zakim> dezell, you wanted to talk about abstraction of wallet
<manu> Ian: It may not be helpful to put payments, digital offers, and verifiable claims at the same abstraction layer - payments have to do with something I want to do over the web, same with digital offers. Verifiable Claims is not an activity in the same way, in my mind. Verifiable Claims is like an abstraction that encompasses almost every sort of utterance you want to make on the Web. it's too broad of a topic to go with the other two.
<manu> Ian: If you want to do payments and digital offers seamlessly, and see how much verifiable claims can help, that makes sense.
<manu> Ian: I can see some disagreement there, but Verifiable claims seems broad. It speaks less than payments and coupons, may need adjustment. List semantics thing that has a bit of friction for me.
ltoth: To summarize, the vision task force doesn't want to lose the topic...but not hearing anything specific new work
dezell: +1 to Ian's comment - get experience through coding and seeing what we need, either in the IG or the CG
<Zakim> dezell, you wanted to comment about running code...
dezell: The IETF has this mantra as well...
manu: I will add the use cases from the vision task force to the Digital Offers CG wiki
(IJ: +1)
ltoth: IG has 90 minutes for us at the IG meeting:
https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Mar2017
<manu> Ian: What is the expectation? To get them to the meeting? Or to do some demos with their stuff?
IJ: Is the expectation to get people from other companies to the meeting or just do their demos?
ltoth: Both
<manu> Ian: Could you work with David on invitations?
<scribe> ACTION: ltoth to work with dezell on a list of invitations [recorded in http://www.w3.org/2017/02/06-digitaloffers-minutes.html#action01]
<manu> ltoth: Yes
ltoth: Once we figure out who wants to demo, we will have a better sense of discussion topic time
(IJ thinks we should be sure to have 1 hour to go through use cases)
(Which means 30 mins at most for demos)
Manu: I would hope to demo storage of coupons and using them in payment apps
ltoth: Would it be better to do the demos up front or after discussion of topics
<dezell> ACTION: Manu to make sure the digital wallet use cases are moved into the Google Doc, Adam to attempt to keep the Google Doc up to date. [recorded in http://www.w3.org/2017/02/06-digitaloffers-minutes.html#action02]
Manu: I have seen it done either way
<manu> Ian: if the Task Force has been working for months, and work unrelated to task force, that would create some dissonance. If demos reflect use cases, that feels helpful.
<Zakim> Ian, you wanted to discuss demos
<manu> dezell: Simon, we'd love to have Kylie there - perhaps she can just walk over?
<Zakim> dezell, you wanted to ask about logistics for the meeting invitation.
<manu> ltoth: Unfortunately, no, she's in the UK. Already sent regrets, I think.
<manu> dezell: We do want to get as many of our digital offers folks as we can to come to the meeting.
<manu> dezell: Simon, don't know if you can get Kylie there, she's important for this meeting.
<manu> Ian: We may need to do that via laptop w/ Skype/WebEx.
<manu> ltoth: I can offer GoTo meeting.
<manu> Ian: I've asked for a polycom system, which we have.
<AdamLake> +1 to next week.
<dezell> +1
RESOLUTION: 13 February noon-1pm ET