Web Payments Payment Architecture Task Force (Friday) -- 05 Jun 2015

<github-bot> [13webpayments-ig] 15dprophet pushed 1 new commit to 06master: 02https://github.com/w3c/webpayments-ig/commit/53e3682df8bf8e295b171f151d2bc8f2bb5111e7

<github-bot> 13webpayments-ig/06master 1453e3682 15Erik Anderson: Update requirements_draft.txt

<dsr> one sec

<dsr> …

<dezell> ?

<dsr> It should work on https://mit.webex.com/meet/draggett

<manu> everyone - dial-in number: 1-617-324-0000 access code: 642 709 188

<manu> AdrianHB: dial in here:

<manu> https://mit.webex.com/meet/draggett

<manu> dial-in number: 1-617-324-0000

<manu> access code: 642 709 188

<manu> scribe: dezell

Face-to-Face Planning

Credentials: https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015/Credentials

manu: we have prepared an outline of the presentation.
... any feedback?

<manu> dezell: Having been a bit AWOL during this discussion - the first thing that I would ask - how would tokens fit into the work?

dezell: I think a token is a credential "bus"

<manu> manu: Tokenization is a part of the work

<manu> dezell: We already have EMVCo token - what do we need credentials for?

<manu> dezell: Tokens are a way of moving credentials around.

<AdrianHB> EMVCo tokens are scope limited - they represent payment tokens only

<AdrianHB> i.e. Replace a payment card

<manu> padler: Whether it's a one-time thing or an interaction thing - we might be able to talk about that in capabilities.

pat: capabilities cover tokens a little more.

<AdrianHB> +1 for us to have some clarification in the presentation around what tokens are (various interpretations) and how credentials relate

manu: credentials tie a real world identity to an on-line identity.

<manu> dezell: If I understand some of Erik's contributions - we need to understand how these things are bound to online identity.

manu: strong binding takes place when producing the credential.
... 2factor hardware (FIDO) that's where that comes in.

dezell: context based components.

<manu> dezell: What about context-based credentials?

<AdrianHB> a credential needs two proofs: 1) that it was issued by a particular entity and 2) that the holder is also the subject

<manu> dezell: Collecting information - geofencing, geolocation patterns, etc.

<manu> dezell: Combined w/ two other factors, that's pretty good identity.

manu: no there is a range of factors.

<manu> dezell: Is everyone insisting on strong authentication?

<manu> manu: No, it's a range.

<manu> dezell: What about Eric's message on scanned signatures?

david: digital signatures vs. electronic signatures?

<dsr> Erik claimed that scanned image of written signatures had greater acceptance than a digital signature

<manu> padler: Some financial institutions still rely on scanned signatures.

<Zakim> AdrianHB, you wanted to discuss elec sigs

pat: not sure why digital signatures are not good enough.

adrian: I think the simplest way to look at credentials is a digital signature from the issuer, and some kind of (flexible) binding to the holder of the credential.
...: it will be up to the consumer of the credential to trust/not-trust the scheme.
... I'm not aware of any legalities around electronic and digital signatures.
... Joseph Potvin has sent some UN information on use of electronic signatures.

joerg: we are already beyond legal regulation for digsig.

<Zakim> manu, you wanted to mention case law on digital signatures. and to table the signatures discussion

joerg: we have legislation to allow usefor contracts, but there is now new regulation that has overtaken it. We can use our id card for KYC.
... there is considerable regional verification.

manu: seems to be a ton of case law supporting digsig. digsig+esig is better, but digsig is still binding.

<manu> dezell: Do we need to keep worrying about TR-4?

<manu> manu: I think we should read it.

manu: current plan of action is to get the payments use cases for credentials laid out.

<manu> dezell: about Credentials charter - are we on a good path?

pat: pages 2 and 3 of the capabilities document addresses the cross-application use cases.

<manu> dezell: We're still pursuing the bigger Credentials scope, but focusing on payments at the face-to-face.

<manu> scribe: padler

Deployment presentation

<manu> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015/Deployment

manu: another presentation at face to face on deployment and adoption of standards iteration..
... this covers what we need to do to promote uptake of standards... and gain support for implementers of the standards..
... please provide feedback as soon as possible... so that people have a chance to read before face to face..

Capabilities document

<manu> scribe: manu

Capabilities document: https://docs.google.com/document/d/1FbHscEFUA1P6Frm9h-98bgBF8oCNNu3_0BZh8l7Aa0c/edit#

padler: Manu, Adrian, Ian, and I have been working a lot on this document - we've focused on the content. We're shifting back away from now/then format to grouping the capabilities by core segments.
... So if you look at bottom of page 2 and 3 - do the coarse grained bundles make sense?
... Core is the stuff that will be used across all other capabilities - digital signatures, data model, key management model
... identifiers... payments identifiers interoperable across identifiers in trust space
... Then there's Trust - which includes Identity, Credentials, Rights, Authentication, Authorization, Privacy, Discovery, Registration, Enrollment and Legal/Regulatory concerns related to Trust and Identity
... so establishing identity before payment happens either via token or some other means.
... Trust - who/what are you and what can you do?
... Third one is value - store of value / representation of value - there are some use cases that doesn't have anything to do w/ payments - for example, looking for balances, etc.
... things like Accounts, Ledgers, and Legal/Regulatory concerns related to accounting and recorded ownership
... Then there's payments - which covers things like Funding, Payment, Messaging, Clearing, Settlement, Markets, Foreign/Currency Exchange, and Legal/regulatory concerns specific to Payments and Exchange of Value
... Then there's Commerce - capabilities related to things that precede or follow the payments process. Things like Offers, Invoicing, Receipts, Loyalty, Rewards, Contracts, Lending, Insurance, Taxation, Legal/Regulatory concerns related to aspects of commercial and economic interactions
... We're going to add examples of these interactions to talk about specific piece of commercial process w/o talking about the entire thing end-to-end. Enables loose coupling.
... So, let's see if there are questions/comments.

manu: Just to mention that I think we have a good general direction now - which is good, Pat and I feel much better about the document now.

<AdrianHB> +1 - doc is looking good and it feels like we are pulling in the same direction toward being able to start defining work

padler: Feedback from X9 folks - being able to talk about specific bits - payer identifies payee based on loyalty number - we've started to add last night, manu did a ton of work on this - what are the deliverables, what are related specs, which standards bodies should we re-use work from?
... Another section that still needs to be added - key concepts that still need to be discussed - not just interactions, but is there a set of atomic asynchronous actions that happen as a part of the payment process?
... Maybe we need to re-introduce the "Agents"
... Really these are just collections of services that the agent interacts w/ or express. Don't know if agents map to each category.
... We may want to list key principles. Also some work to do in guiding principles / high-level requirements.
... For example, stuff about identifiers - they're specific - guiding principles - anything that's broadly applicable - defaulting to a position of not sharing information unless it's required by law (privacy)
... Look at page 4 - bottom of page 4 - Core Capabilities: https://docs.google.com/document/d/1FbHscEFUA1P6Frm9h-98bgBF8oCNNu3_0BZh8l7Aa0c/edit#heading=h.y35m67n9nb8s
... Data model, key management, cryptographic signatures
... what do we need to provide in terms of digital signatures - looking across capability segments, it became pretty apparent that it's important to have 'identifier model' that's used across different capabilities as well as key model.
... offers to invoices to payment request - each one of those things should be able to be signed or read using a consistent key management model.
... The information about that whole transaction would need to be consistent from start to end.
... going through core capabilities for the section - describe key concepts specific to core
... Then we have suggested deliverables
... "The Related Specifications" bit will help to draw out if there is another spec that we should look at.
... What do folks thing about the document so far?

AdrianHB: Quick question - you separated out "value" from "payments"
... What was the thinking there?

padler: There are use cases where someone wants to query or interact w/ their accounts in a way that doesn't require a payment or exchange to take place.

AdrianHB: I had similar thoughts - I was staring at that group of capabilities under account - there are payment accounts, loyalty accounts, and they all that some relevance in other places. Was thinking of relationship between identity and commerce/payments.
... Part of use cases in commerce world as well as payment world - I would think of it more from the perspective of - for me it's more about accounts and custodianship than value.
... The name 'value' is misleading - I think we should have the capabilities group - will give it some thought - need a better name for it.

padler: Maybe a better term is like "ownership"? This is the collection of things that reflect how much value you have in a deposit account (where someone is holding value for you), or when someone has recorded assets (due to a contract), or some kind of loyalty record. You don't physically/virtually owned the data it's just a record/ledger.
... I think we can tweak that.

manu: "Value" feels a bit amorphous - hard to figure out what we can deliver for that.

AdrianHB: Maybe we should merge that section into the others - checking account balances are really a 'banking' use case.

padler: Banking, wrt. lending - feels like commerce.
... Use case where I need to fund a payment transaction - I'd like to have a consistent way of representing that. Incorporate that into transaction?
... Maybe that's not a high-priority use case?

AdrianHB: representing that source of value?

padler: Where does the payee go w/ the acknowledgement of the payment? If you're doing straight through processing on the entire value chain - it would come to rest somewhere in the payee's ledger.

AdrianHB: For me, that starts to sound like what we're doing in settlement.
... That part of it could fit into payments under payment capabilities. The way I was thinking about payments as commerce - a lot of what's in commerce isn't regulated, but it's dealt w/ law - legal considerations (commerce) and regulatory considerations (law)

padler: Scaffolding allows people to plug into standards - important that we don't bundle trust stuff in payments. Trust is useful outside of payments, it gives you a note that trust is independent, loosely coupled from payments and exchange. You use trust in lots of other ways.

AdrianHB: Agree.

<Erik> Strange. I was on the call earlier but no one else was on.

<Erik> Said I was the 1st participant.

<Erik> Oh. Thats why

AdrianHB: We should see how many of the value capabilities we can put under other categories. If we can't do that - we may need a better option.
... Maybe we create a "Settlement" category and move things into that.
... I think it makes sense to create Settlement and then move accounts, ledgers, and clearing into that category.

<Erik> Please, in the future, DONT switch conference providers without updating https://www.w3.org/Payments/IG/wiki/Main_Page#Teleconference_Logistics

<Erik> Better yet, send out appointment invites with the call information like the rest of the world does

Erik: Zakim was broken this morning, it was an emergency switchover

<Erik> Ah, :(

padler: by early next week, we might grab what's in Google Docs and put it into ReSpec

<dezell> zakim is becoming bitter.

<Erik> Whats the call info?

<Erik> I have 2 minutes of material to cover

padler: To close this comment out - other two pieces that we wrestled with - we don't have a representation of wallets or stored value cards. Deposit accounts/digital wallets.
... We may need to figure out how to fit wallets into this - android pay, apple wallet.

<AdrianHB> https://mit.webex.com/meet/draggett

<AdrianHB> dial-in number: 1-617-324-0000

<AdrianHB> access code: 642 709 188

padler: If folks have questions, drop us an email on the mailing list or ping us on IRC - we'll update as necessary.

in US Fed Task Force call

Erik: There are 5-6 more bullet points that were covered in US Fed call - lots of good research/docs

<padler> are those minutes public

Erik: I'll have it done by the weekend.
... Yes, they're public - I'll give link to PDF and documentation - yes, that stuff is public. Will send to IG list.

<AdrianHB> +1 to sending to ig list, thanks erik

padler: We're at a point where the Capabilities document is getting into shape. Should make it easy for you to plug those bullets in there.

Erik: Should have it done by Sunday - only made it through 1 out of 8 docs they sent out. Trying to boil it down to 4 more points.

<jheuer> need to leave. Sorry. Ciao. Jörg

s/15dprophet pushed 1 new commit to 06master: 02https://github.com/w3c/webpayments-ig/commit/53e3682df8bf8e295b171f151d2bc8f2bb5111e7//

s/[13webpayments-ig] 15dprophet pushed 1 new commit to 06master: 02https://github.com/w3c/webpayments-ig/commit/53e3682df8bf8e295b171f151d2bc8f2bb5111e7//

s/13webpayments-ig/06master 1453e3682 15Erik Anderson: Update requirements_draft.txt//

s/ …//

s/It should work on https://mit.webex.com/meet/draggett//

i/scribe:manu/Topic: Capabilities document/

- DRAFT -

Web Payments Payment Architecture Task Force (Friday)

05 Jun 2015

Attendees

Contents

Face-to-Face Planning

Deployment presentation

Capabilities document

Summary of Action Items

Scribe.perl diagnostic output