Web Commerce Interest Group

25 Oct 2018

Agenda · 26 October minutes


Cyril Vignet (BPCE), Gildas Le Louarn (Lyra Networks), Vincent Kuntz (SWIFT/ISO 20022 RA), David Ezell (NACS), Adrian Hope-Bailie (Coil), Phil Archer (GS1), Lawrence Cheng (Barclays), Linda Toth (Conexxus), David Ballaschk (Deutsche Bundesbank), Ian Jacobd (W3C), Krystian Czesak (Shopify), Takashi Minamii (JCB), Nicolas Ancot (Canton Consulting), Jean-Yves Rossi (Canton Consulting), Ken Mealey (American Express), Angel Li (Alibaba), Eric Siow (Intel), Dae Hee (INCA), Tzviya Siegman (Wiley), Karen Myers (W3C), Jeff Jaffe (W3C), Christopher Allen (Spec-Ops), Daniel Burnett (Independent), Matt Stone (Independent), Dmitri Zagidulin (Digital Bazaar), Manu Sporny (Digital Bazaar), Arnaud Le Hors (IBM), Allen Brown, Richard Esplin (Evernym), Kenneth Ebert (Sovrin Foundation). There were also other presentatives from the Credentials Community Group and Verifiable Claims Working Group for those joint discussions.
David Ezell
Ian Jacobs, Karen Myers


EU payments update

<Ian> David Ballaschk (Deutsche Bundesbank) Slides

<Ian> dballaschk: My role at the bank is to advise the commission in the early stages of the regulation

<Ian> ...it's important for regulators to speak with technical people to improve regulations

<Ian> ...harmonized SEPA payment landscape

<Ian> ...clouded by Brexit

<Ian> ...specifically in Germany, we remain cash-heavy, medium use of cards, integral part of SEPA

<Ian> ...big market in terms of credit transfers and direct debits; interchange limit has led to growth in credit cards, as well as contactless UX

<Ian> ...Germany among world's largest direct debit markets

<Ian> ...PSD2 has been one of the most important topics in the past years

<Ian> ...in Germany, market is roughly divided in three parts depending on account type

<Ian> ...the issue that brought PSD2 to the market was that SOFORT brought APIs to the market and the banks didn't want that.

<Ian> ...the EU Court decided users needed to have the choice

<Ian> ...data belongs to the customer

<Ian> ...so PSD2 involves (1) open banking accounts and (2) strong customer authentication (SCA)

<Ian> ...what became clear during the process was that the regulators did not have the full vision of technology implications of the regulation

<Ian> ...for access to accounts we are still working on the APIs

<Ian> ...the National Competent Authorities (NCAs) (mostly the central banks) have to figure out some criteria whether banks need or don't need to provide a fallback option if they don't have a compliant API; the criteria are not yet clear.

<Ian> IJ: What does "fallback option" mean?

<Ian> dballaschk: You have the API...the fallback option is "screen scraping"

<Ian> ...in the fallback option, the Third Party Provider (TPP) has your credentials and logs in as you.

<Ian> ..the problem is that, as a bank, you don't control in this scenario what the TPP is doing.

<Ian> ...the problem with the fallback option is also ensuring that only a certified TPP can access the account.

<Ian> ...as a regulator in germany, we don't actively encourage (and banks discourage) use of TPPs

<Ian> [Slide on Timeline]

<Ian> 14 March 2019: APIs published

<Ian> 13 June 2019: Market tests

<Ian> 14 Sep 2019: TPPs access via dedicated API

<Ian> ...there are five API initiatives:

<Ian> - Berlin Group

<Ian> - STET

<Ian> - Poland and friends

<Ian> - Open Banking UK

<Ian> - ??

<Ian> ...I think it will be difficult to meet the deadlines. E.g., more than 200 flavors of the Berlin Group standard so far in different implementations.

<Ian> ...that means 200 variations on the standard; so need some harmonization

<Ian> ...regulators watching the progress of the various APIs.

<Ian> Lawrence: Where does testing take place?

<Ian> Dballaschk: Expectation is that transactions will take place in a sandbox. e.g., a pre-selected user group...like a controlled pilot

<Ian> ...will be people from the TPPs likely who test their implementations in the market

<Ian> Ken: Thanks for joining us. Changing behavior is tricky. To bring about change in this market, are there key performance indicators or a time frame?

<Ian> Dballaschk: We don't have any particular success criteria, but regulations are reviewed regularly. We listen to the market. If TPPs tell us it's not working, we will hear that.

<Ian> ...but there are no rigid criteria we are looking at.

<Ian> Ken: Why is there not aggressive competition?

<Ian> Dballaschk: I think it's because of the different focus (in germany)....different types of banks, also small banks in the case of collective/customer...and also regionally distributed; they don't really compete against one another in their respective markets.

<Ian> ...some more competition more recently due to low interest rates

<Ian> ..note that I am speaking about the German market only

<Ian> Cyril: PSD2 came about because of the German market situation. In France it was different. Why are you finding there are so many competing implementations (of the Berlin Group API)?...it's obvious most banks will implement internally since there are not yet off-the-shelf solutions...it seems obvious for now that it will take a while for implementations to converge

<Ian> dballaschk: The main concern is that API friction will make it hard for small services (e.g., documentation can be hard to translate or not friendly)

<Ian> vkuntz: Regarding the APIs in development; from an ISO 20022 perspective we are getting more alignment via ISO 20022 as a common denominator...also got some traction with Open Banking UK...there was an announcement this week at SIBOS that STET and Berlin Group will align on their next version

<Ian> dballaschk: We will closely monitor implementations of the API. Note that TPPs don't get personal data. You've heard of GDPR...GDPR goal is to give consumer power over their own data....banks won't give out data to TPPs without user consent...different roles: PISP, AISP, card issuer. I spoke to the EBA a couple of weeks ago. The guidelines for NBAs regarding exemptions (and use of fallbacks) will be available by end of 2018...main concerns at the moment...design and testing of infrastructure to the satisfaction of the TPPs....calculation of downtime...how much is acceptable? when do you need to all screen scraping? will NCA be able to withdraw exemptions and under what circumstanes...should TPPs be involved in the exemption process...clarity on future timelines (e.g., testing). SEPA took a long time; I hope that we are faster with PSD2

<Ian> [Instant payments slide]

<Ian> dballaschk: There are faster payments initiatives in different regions (e.g., UK, US, ...). From Nov 2017 it was technically possible to do account to account transactions among participating banks within 10 seconds on any day at any time...what's new for us is a payment flow in two directions..."TIPS"...liquidity on TIPS account is included in the minimum reserve calculation...TIPS-Costs: no fixed fees, no joining fees, .002 EUR per transaction...some banks were reluctant to implement due to risk associated...so we offered incentives as a central bank...this will start on 30 Nov (thus, next month) ...because ACH's demand fixed fees and joining fees, it's not a big incentive for small banks to join an un certain scheme for high cost where they have few transactions. Hence TIPS costs are low...each originator bank (sender) pays .002 EUR

<Ian> Ken: Are faster payments initiatives about "faster" or "cheaper"?

<Ian> dballaschk: If you ask merchants they will say "cheaper" (wrt cards). For the customer, it is about faster payments. with SEPA most payments are same-day...so value for customer of faster payments is not immense

<Ian> AdrianHB: no credit transfer payment system today is useful in retail since not instant; so when it becomes instant becomes more interesting in retail

<Ian> dballaschk: I think that instant payments might increase competition with card networks. For example, in retail you could use direct debit with instant payment...as an analyst, if instant payments take off it doesn't make sense for banks to offer either standard credit transfers or standard direct debits

<Ian> Ken: when you talked about banking competition in Germany was that about banking services generally or specifically about payments...in the US there has been debate about issuing licenses to Fintechs so they can compete on payments, but the regulation of banks is much broader in scope

<Ian> dballaschk: I don't think there was a focus on payments in Germany since so cash-centric for so long until recently. In the US, interstate payments were particularly tough

<Ian> CYrilV: Push payments are often not compliant with commerce rules...due to requirements around shipping...whereas pull payments are better for that

<Ian> dballaschk: We have the same issue in Germany...there is an opportunity to pay in advance, but it's not popular since it pushes all the risk to the customer...we have concerns about ecommerce fraud with instant payments...I think the biggest merchants will be most interested by instant payments due to automation opportunities.

<Ian> AdrianHB: In south africa, we have a credit transfer (EFT) and had real-time credit...so clearing to the receiver's account in 30 minutes....we've had it for over 10 years...the banks never phased it out...they just charge more

<Ian> dballaschk: In Poland they've had instant payments for 7 years; they charge 2 Euros per transaction. Of course it makes it impossible to do instant payments at the POS since customers won't pay more so that merchants will get their money faster.

<Ian> ancot: What are the deployment strategies?

<Ian> dballaschk: The problem that I see at least in Germany, is that some banks said openly "instant will be free with us"...N26, Santander...then you are going to have customers that say "I have to pay 1 or 2 EU at my savings bank but can do it for free at N26"...so there is already market pressure to offer the service for free

<Ian> ancot: Is there any adoption strategy related to merchants?

<Ian> dballaschk: I don't see concerted marketing actions yet...I can imagine that the big players at the POS (e.g., for supermarkets) could offer rebates if you use instant payments....e.g., via a retail app...merchants depend heavily on the banks...so one initiative by the POS players, not backed by banks; and another by online players backed by banks

<Ian> lawrence: Any thoughts about consumer protection if it moves to POS?

<Ian> dballaschk: There are questions, of course....we already have some cases of fraud with instant payments...liability lies with the bank...as long as the customer does his due diligence

<Ian> Lawrence: In the UK faster payment is considered e-cash. I'm hearing that's not necessarily the case in Germany

<Ian> dballaschk: That's right, more like ordinary credit transfer.

Verifiable Credentials

Dan Burnett Slides on Verifiable Credentials Progress Update

<AdrianHB> dan: verifiable claims vs credentials

<AdrianHB> ... name has changed over time but they are interchangable (preferred name today is credentials)

<AdrianHB> ... [mission and goals slide]

<AdrianHB> Dan: People carry credentials today, but no great way to express that digitally today in a way that is easy and secure in the right way... we care about claims that can be verified. by a 3rd party but where the owner has control of how it's used... a verifiable credential allows a credential issuer to make a "statement" or "claim"... verification is NOT verification of the truth of the claim, it is verification of (1) the origin of the claim and (2) that it has not been revoked. Note these are verifiable, not verified credentials

<AdrianHB> manu: example: I can say the sky is purple and verify that I said it but that is not true ... attributes like my height are a credentials

<AdrianHB> angel: another good example is a claim of being "over 18"

<AdrianHB> dan: the point is that we need to be able to make that claim without giving away personally identifying information (such as the actual date of birth). In scope: we are chartered to create a data model. Out of scope: protocols and APIs and the larger problem of "identity" on the Web. Scope includes core vocabularies for (for example) the subject of a claim

<AdrianHB> ????: getting close to end of charter. Market interest has been very positive. Lots of interest in finacial services/commerce also in logistics (example: verification of license status)

[Scribe switches from Adrian to Ian; deliverables slide]

Dan: use cases, data model and representations, test suite
... lots of activity around the data model spec (in terms of issues opened and addressed)

Decentralized Identifiers (DIDs)

[ Kim Duffy Slides]

Kim: You can prove control over an identifier via cryptography
... does not require a centralized administrator
... lots of support in industry, for example, around transport, insurance, government, banking

phila: You gave the example of a driver's license with an identifier. Would you put a DID on the driver's license, or some sort of QR-code like presentation?

Kim: We don't see it being used as a credential that would be printed on a driver's license. We can do more privacy-protecting things
... the DID is the string that is the subject of the credential
... the DID is an indirection; you can rotate keys associated with the identifier
... the DID method explains how to find the associated keys
... the lifecycle of the keys is thus built into the process

phila: If you were to add machine-readability to the DL, could you offer both a human-readable string and machine-readable version?

Kim: We don't want people to have to deal with opaque strings.

ChristopherA: It's a bit method-specific. That particular encoding in this slide has some built-in error correction.

Kim: Sovrin has done the most usage studies.

nage: The implication of this example is saying "this is a kind of identifier" but the properties of the identifiers require more consideration
... credentials are more types of attributes than just identifiers.

@@: People interact with DIDs through software; often through a friendlier name.

Kim: The anticipated user experience would be friendlier than interacting directly with DIDs. "Pet names" for DIDs are being incubated in the ecosystem; not standardization activity at this timer

<nage> we like to talk about these specifics. Please reach out to members of the VCWG for clarifications, we are very happy to help.

<BrentZ> +1

Kim: We are getting government support (Canada, US in particular)
... one benefit is preventing counterfeit...so play a role in imports/exports

Kim: The Credentials CG continues to grow;
... we are interested in starting a DID Working Group at W3C
... please come to the W3EDC Workshop on Strong Authentication and Identity in December in Redmon.

Progress on WebAuthn + DIDs + VCs

[Manu Sporny's slides]

Manu: We want to bring hardware-secured devices into the ecosystem.
... e.g., hardware keys à la WebAuthn
... some of these keys are also biometrically secured
... WebAuthN is being implemented in all browsers
... WebAuthn has two phases (1) enrollment (2) usage
... responses to challenges are origin-specific; thwarting replay attacks
... one hope is to replace passwords
... ideal user experience is to use built-in two factor authentication in place of username/passwords
... site (relying party) issues a challenge; the user unlocks a key with a gesture; the key is used to sign reponse
... verifiable credential life cycle is similar:

manu: Devices can be registered with a DID


Manu: The browser in this demo is a chromium custom-build
... in order to use the device, what I need to do is allow my digital wallet to handle credentials on my behalf.
... I register my key with my wallet
... I touch my yubikey and confirm I want to register my key with my DID and verifiable credentials.
... next I want to use it
... to buy an airline ticket.
... I will need to provide a passport credential.
... the site asks for passport credential.
... the wallet asks whether I want to sign the credential when returning it to this site
... I say "yes" then touch my yubikey
... that causes the credential to be encrypted and sent over.
... we think this is as safe and easy as you can get today
... more keys will be built into other hardware, like laptops and phones

IJ: How does the airline verify the signature?

Manu: The relying party gets the signed packet. Sees that it was digitally signed with a DID.
... it then looks up the key information associated with the DID; does key discovery
... one thing that it will find is a hardware backed key.

IJ: Did you have to enroll with the airline? How does identity proofing happen?

Manu: The airport can ask for an identity proofing credential. For example, have you appeared before any authority with this key and do you have proof of that?
... so a person can go to the US Post Office who is authorized to do identity proofing for passports.
... so from the wallet the user can send over both a passport and a credential that enables identity proofing
... Note that this level of identity proofing may not be necessary in all use cases.

Ken: Can private key reside on phone?

Dmitry: Yes. Works with mobile phones, built into the apple touch bar, etc.

Manu: For next steps, wWe are doing privacy/security analysis (e.g., with FIDO). We need the WebAuthn support in IFRAME elements

<nage> There is still some controversy around how some of this key binding relative to the privacy shakes out

Digital Offers Update

[ Linda Toth's Slides]

ltoth: We have spoken about digital offers previously in the Web Commerce IG; today I will talk mostly about what's new.

[Slide: Why digital offers]

ltoth: In-app offers are siloed; we could do more if we have an open ecosystem (the Web)
... that would increase availability and reduce channel friction
... they would like to do this in different channels and markets
... we'd like to improve the digital offer experience...today many digital offers are based on "grocery store" use cases rather than "convenience store" use cases.
... e.g., "family codes" are common in grocery but not convenience

<scribe> [Slide: New since 1 year ago]

ltoth: We have some traction regarding identity
... last year we talked about a coupon bureau ecosystem and that work is advancing; we are starting to do pilot projects
... verifiable credentials would allow us to address more use cases
... bar codes allow us to address some cases, a coupon bureau would allow ut to solve more, verifiable claims would enable us to solve them all.

[Slide showing coupon bureau ecosystem]

scribe: the bureau would be an independent entity that can validate offers in the background.
... the bureau is a joint effort of GMA and JICC (part of GMA)...they worked with some other orgs including GS1
... the coupon bureau will be a non-profit, centralizing validation
... when the consumer gets an offer, they present to the merchant; merchant presents to the bureau for validation
... merchants are reluctant to send "basket" information for privacy's sake.
... the bureau is becoming a reality; they are in pilot now...they would likely launch in 2019
... we are part of the pilot project

dezell: Nobody is really 100% happy with a single coupon bureau; it's part of the pilot
... conexxus has some plans for integrating with the pilot; there are some aspects of this ecosystem where W3C can play a role.

ltoth: Loyalty can be stacked on top of bureau
... they can work in conjunction
... I shared concerns about a centralized bureau; merchants unlikely to pay....it's the CPG's that would pay for the handling.

[On NACS and Conexxus]

ltoth: In the US, there are 154K convenience stores; that's more than grocery/dollar stores/convenience stores combined]
... we do 160M transactions per day; about 50% of the US population
... so digital offers are important to many people
... $237B in 2017
... tobacco is 34% of sales; as smoking declines, manufacturers are focused on brand-switching; high-dollar offers
... retailers are stuck in the middle while digital offers have not been sorted out
... we also do a lot of beer 9%
... we need to verify age for both alcohol and tobacco ... there are important identity issues to ensure users are "of age"

[Why the Web benefits digital offers]

ltoth: order ahead, accurate product availability; single channel
... merchant requirements: validating consumer
... NACS and Conexxus partner together; can do outreach to CPGs and advocacy with industry merchants
... conexxus has a mobile payment standard
... for payments at the gas station
... we also want to enable real-time settlement
... we want to figure out how to make this work together in one ecosystem.

IJ: In addition to the credentials part of digital offers, we've discussed within W3C opening up the coupon ecosystem so that browsers and third-party handlers could facilitate user interactions to clip and redeem coupons. There is no traction right now for those ideas, but the coupon bureau people expressed some interest, so we plan to continue those discussions after the pilots (when we expect to have a better idea of traction of the coupon bureau).

Credentials CG Roadmap for Decentralized Identity

[ Joe Andrieu slides]

Joe: Identity is how we recognize, remember, or respond to specific people or things
... digital identity involves tools for managing identity
... our goal for decentralized identity is that "it just works and you can build any kind of systems on top of it"
... current efforts involve verifiable credentials; DIDs
... goal is to move to a plurality of authorities (decentralization)
... trust comes from multiple sources of information, across multiple interactions
... you respond based on the information you receive from multiple sources

[Slide showing a "stack"]

Joe: DIDs, DID documents, raw data, verifiable credentials (authorities say something about data), profiles (built from credentials), consent (records of authorization, usage rights), reasoning (interpretation and analysis), understanding, services (interactions of value)

[Potential standards work]: pet names, identity assurance, Credential requests...enable more than one wallet to respond to requests, consent, storage and internal representations, analytics and algorithms for evaluation.

<dmitriz> We need a better term than "Pet Names" for the system. <- this came up with discussion with Christopher Webber, who is working on some Pet Names systems at RWoT; see Petnames for Self Sovereign and Human Readable Identifiers. Specifically, the concern is that many audiences will react very negatively, and with confusion, to the term 'petnames'

Joe: standardized analytics would be interesting as well as cryptographic suites. Here's a roadmap document [Diagram shown]

JeffJaffe: Thanks for the fascinating presentation. Since this is the Web Commerce IG, any response from commerce people on the applicability of this work to web commerce?

Joe: Possibility of using on-chain settlement rather than talking to coupon provider for settlement
... one of the challenges is that a lot of our work is meant to be privacy enabling; some of the commerce goals are related to customer tracking

IJ: Can you do tracking without strong identity?

ChristopherA: Yes.
... zero knowledge proofs that don't enable correlation
... there was another item on consent receipts; to comply with GDPR and similar ... you can ask for information and a consent receipt allows you and another party allow clarity on usage policies
... both of those are relevant to coupons and commerce

dezell: We have been interested in this technology for compliance
... e.g., ensuring age-appropriate sales
... could give us the right level of compliance without revealing individual identity

Manu: There are multiple large govs interesting in trade finance; they are interested in some of the technologies on this map in POCs and pilots in 2019
... that is a form of commerce (but beyond payments)

AdrianHB: From a payments WG perspective...I raised with the TAG the pattern of matching service requestors and providers; this is a similar pattern requesting credentials and responses with credentials drawn from multiple wallets.


[Arnaud Le Hors Slides]

arnaud: I spend most of my times these days at Hyperledger; this will be a general overview
... this will no be a technical presentation but more about the organization and its projects
... we can talk about potential links with W3C

[Business networks]

arnaud: Businesses don't function in isolation; they'll create wealth by transferring goods and services within their network
... including suppliers, customers, regulators, and other parties
... there are different types of markets (both public and private)
... people have used ledgers for a long time to keep track of transactions within the network
... a contract defines the conductions under which the transactions happen
... people moved from paper ledgers to database
... but databases have been siloed
... when an issue arises, can be difficult to determine the source of truth when there is more than one source of record.
... you go through a time-consuming and inefficient reconciliation process.
... this is where blockchain comes in
... it is a shared ledger
... every party can have their own copy of the ledger, and the system ensures that they stay in sync
... blockchain enforces reconciliation up front
... the system lets you submit transactions, and when everybody agrees the constraints have been met, you record it and everyone shares the same view
... what's new then is not the concept of ledger, but the concept of shared ledger


arnaud: Bitcoin is an application of blockchain; designed with specific network choices and characteristics
... designed to be completely open; designed for particular kind of token
... there are costs to that approach; e.g., the system has to protect itself against its public clients
... by definition the system cannot trust anyone
... the "proof of work" goal is to make it hard to rewrite history
... each block has a set of transactions; it is digitally signed
... and it refers to the previous block...
... and this is key to making it hard to rewrite history
... bitcoin also has social incentives; rewards for stabilizing the blockchain
... the whole system would fall apart if you removed the proof of work
... the cryptographic challenge takes about 10 minutes (to create a new block)
... if you wanted to rewrite history you would have to rebuild a new block, resolve the cryptographic challenge to sign the block, and then do so for every other block.
... meanwhile, the rest of the world keeps creating new blocks, and it becomes impossible to keep up


Arnaud: For bitcoin you have one or more identifiers. If you want to exchange a coin with me you give me an identifier. With that identifier I can see all the transactions you've done and will do forever; that's a bit of a privacy issue

[Business networks]

Business needs are different than bitcoin drivers. Key things for business are:


arnaud: Everledger is a small company that had the idea of using blockchain to keep track of diamonds
... when a diamond is mined they create a digital signature for each stone
... they register the provenance of the stone in a ledger using that digital ID
... and all transactions that relate to that identified stone are recorded in the ledger
... you could do this with a centralized system, but nobody trusts a single party to hold the truth for them
... the stakeholders involved are certification agencies, stone-cutters

<jeff> Ian: In an open network you don't need to know the players; but you do in a business network... does that mean you trust them all?

arnaud: Trust is not binary. Businesses, when they enter a business relationship, they trust the other party to fulfill a contract, but they don't necessarily trust them for holding the truth about how a contract was carried out
... In many cases today, the traditional model has a central truth-holder
... there are costs and challenges associated with that.

[Food safety scenario]

Arnaud: FoodTrust is an application developed in China with Walmart to track produce provenance
... Carrefour just joined the project
... the idea is to be able to trace product origin
... until arrival on the shelf
... e.g., this helps with recalls in case of contamination
... there's an IOT component here as well; you can do temperature testing and ensure that cold chain has been preserved

dezell: Have people thought about using this for something like GMOs?

Arnaud: Today we are developing different platforms. These are permissioned networks; you can't scan for them; access is controlled
... we have different projects around the world.
... what will happen eventually is we'll have network of networks
... That's when standards will come into play! The projects I've referred to are deployed and international.

Ian: you had proof in Bitcoin network of cost and benefit
... what forms of proof of work do you use here?

Arnaud: When you are in a permissioned network, you can get rid of proof of work.
... proof of work requires time (e.g., 10 minutes)
... there are algorithms for convergence but they involve heuristics e.g., "wait for 3 blocks". We don't need proof of work in permissioned networks since we know participants.
... first, you can revoke access to remove bad players
... second, there's a legal framework behind this
... without proof of work, the systems become must faster

Krystosterone: Where does IBM blockchain come into play?

Arnaud: We took our code and gave it to Hyperledger
... to develop it in open source; we are wrapping the code in a cloud-based offering
... Hyperledger is a consortium; "Blockchain Frameworks" is the system you install to create an instance of a network dedicated to a specific network.
... another project is cross border supply chain with Maersk
... the biggest cost is to keep track of paperwork associated with containers (not the location of the containers themselves).
... paperwork is a compilation of all sorts of paper from a variety of agencies and companies
... there are custom authorities, tax authorities, etc.
... the papers flow through a different route than the actual container
... so we created a consortium (TradeLens) to enable tracking. Each container has a unique identifier
... all transactions for that identifier written to the ledger

[About Hyperledger Consortium]

Arnaud: Collaborative project hosted by the Linux Foundation. Goal was to find a venue for industry to develop blockchain-related technologies in open source
... all the projects use the Apache software license

[About the Linux Foundation]

Arnaud: They have a "Consortium as a business" model
... IBM has been involved in many projects run within the Linux Foundation
... so Hyperledger lives in the Linux Foundation framework.
... within Hyperledger we have different projects
... there are "frameworks" and "tools"


Arnaud: Fabric was contributed by IBM
... designed for business; there's a notion of smart contract
... where logic of the application of the network (conditions for a transaction) are embedded
... the smart contract is a key element of a blockchain network; logic of application is embedded there; there's a security aspect that is very important.
... different projects have taken different approaches
... for example, Ethereum decided to limit what you can do by using a limited set of instructions
... with Fabric we use a different approach to secure the contracts
... In Fabric we introduced the notion of "Channel" to manage access rights
... different granularities of control are available
... a key characteristic of Hyperledger is open governance
... there's a life cycle for each project; technical steering committee is responsible for direction of the consortium; we approve project proposals.
... there's a set of criteria to move from incubation to active
... one criterion is that there's not a bottleneck in terms of "single point of control"
... within the first year we put a lot of effort into the governance questions.


Arnaud: Contributed by Intel
... a concept of "proof of elapsed time" which is a novel consensus algorithm
... you go to hardware to get a random time to wait and a time stamp; you wait that time and you get a certificate that you waited, and you can declare victory as though you had resolved a cryptographic challenge
... the big difference is that it takes little energy


Arnaud: Contributed by soramitsu, hitachi, NTT Data and Colu
... written in C++ (rather than Go)
... architecture is similar to Fabric
... focus is mostly mobile payments


Arnaud: Contributed by Monax
... first permissioned ledger with support for the Ethereum Virtual Machine (the part that executes the smart contracts)
... it's permissioned
... it's licensed under Apache


Arnaud: This is the closest to what's going on in w3c
... contributed by Sovrin Foundation
... developed for the purpose of self-sovereign identity
... cf the DID/VC discussion
... focuses on identities rooted in blockchains
... utilizes zero-knowledge proofs to provide verifiable claims

Hyperledger tools

IJ: Do you use tools to build frameworks?

Arnaud: No. They tend to be on top of them or between them


Arnaud: Quilt was contributed by Ripple and NTT Data
... java implementation of the interledger protocol
... cf Adrian HB


Arnaud: Fabric is low-level. It's just bits. Fabric doesn't know what keys mean or values mean. A bit low-level for business developers
... so Composer provides a higher-level of transaction.
... e.g., transaction types, assets, etc.

AdrianHB: Is the logic packaged as chain code?

Arnaud: Yes


Arnaud: Cello makes it easier to deploy a blockchain network.
... used for DevOps
... e.g., if you wanted to deploy Fabric (which has a bunch of pieces), you could use Cello to make that easier.


Arnaud: Let's you explore your blockchain from a browser


Arnaud: Framework for performance testing
... currently supports Fabric, Sawtooth, Iroha

Hyperledger Working Groups

Arnaud: Hyperledger has Working Groups that are like W3C groups. They aren't focused on code but rather like discussion fora (e.g., health care), or that produce (non-specification) documents
... the Architecture Working Groups is populated by Framework architects, to generalize the various architectures into a common architecture
... Identity Working group ... there is an interest in the combination of blockchain and identity
... people are trying to leverage blockchain to store identity that is not under the control of a single party
... but there is also permission network requirements where identity management is a part of permission management
... finally, Hyperledger Labs (like W3C CGs)
... we shamelessly reinvented the CG concept in Hyperledger

Hyperledger, Open Source, and Standardization

Arnaud: Huge momentum
... There are many companies on the user end of the spectrum who are members (compared to the tech provider end of the spectrum)
... all of this is done in a completely open environment where membership is not required for participation
... but we are getting (financial) support from companies
... we do a lot of outreach (e.g., via meetups)
... People ask me "What about standards?" Right now we are focusing on open source. We had a workshop with W3C on Blockchain where I said it was too soon to create a standard.
... we went through major redesign after the first year
... the technologies are so new and evolving so fast, there is no time for standards.
... there IS an ISO group that is focusing on high-level architecture WG work
... working on terminology in particular
... of course, the self-sovereign identity is more prone to standardization
... interop is key and the system won't make sense and won't be adopted if there's not interop
... when it comes ot the frameworks I talked about, we for now are focused on the different networks.

<nage> +1 to standards being core to interoperability for credentials and identifiers

Arnaud: but at some point they will need to interconnect at which point standardization will be important
... At the application data level, they are leveraging existing (database) standards
... whether GS1 or something else
... what I'm talking about here is how to interconnect frameworks.
... you connect an operation in one network to another; first transaction is a precondition for something that will happen in another network.
... that's where the network of networks will come into play

phila: Interop between networks needs to happen. GS1 has a standard for events in the supply chain
... don't want to expose information that can be used as an attack vector (e.g., where all the stock of product X is)
... I do care about provenance
... I would like an API for access to publicly available provenance information

Arnaud: We would expect someone to control that
... There are things we are doing in Hyperledger Fabric to leverage more cryptographic techniques. There are a lot of use cases related to zero-knowledge proofs
... e.g., identity and correlation ... we have mechanisms now to hide identity of participants

Nage: Some collaborations are already happening on this topic

AdrianHB: On standards and blockchain. I agree that it's too soon for standards over blockchain. Where I think it is important to consider blockchain is that it changes ASSUMPTIONS of some standards development, especially around assumptions of centralized control
... so changes some background/architectural thinking
... DIDs is an example

Digital Contracts

[Allen Brown Slides]

<AdrianHB> allen: Abbreviated version of a previous presentation done at ANSI X9

<AdrianHB> ... longer version available

<AdrianHB> [ reading slides ]

<AdrianHB> allen: I have seen these types of contracts done on blockchains

<AdrianHB> [ table comparing analog and digital contracts]

<AdrianHB> allen: behaviour expressed as algebra

<AdrianHB> ... state changes through exchange of messages

<AdrianHB> (overbar is a send and absence of overbar is a receive)

<AdrianHB> [ explaining 3 stakeholder state changes on slides]

<AdrianHB> allen: To combine these 1-body problems we define rules that evaluate then in parallel

<AdrianHB> ... the contract between the 3 parties is the parallel composition of their 3 behaviours (Calculus of concurrent systems)

<AdrianHB> [governance]

<AdrianHB> allen: why use DLT tech?

<AdrianHB> ... provides a chronicle of evolving state

<AdrianHB> ... but stakeholders don't want a single shared database

<AdrianHB> ... a path through the graph that represents the contract is an "execution"

<AdrianHB> ... to put this on a DL we records states and transitions in order

<AdrianHB> manu: I assume the formalism here will lead to a smart contract language? Is that what you propose to be taken on by W3C?

<AdrianHB> allen: Yes. I am interested in targeting existing smart contract languages.

<AdrianHB> manu: How far away are we from getting the right communities together to talk about this. Tezo, RChain, Mark Millet etc are all working in isolation. How do we get them to gether?

<AdrianHB> allen: This could be started at W3C

<AdrianHB> manu: We could also do this at Rebooting the Web of Trust ... target getting people working on provable smart contracts

<AdrianHB> dan: What would be the goal of a workshop? There are people at Consensys looking at this. There is a difference between enforceable and unenforcable contracts, provable or not.

<AdrianHB> allen: I hadn't considered the need to include lawyers

<AdrianHB> dan: depends on the goal.

<scribe> scribenick: Ian

Karen: A couple of months ago I was contacted by the Accord Project
... a non-profit of legal firms worldwide
... they have some smart contracts that they are considering bringing to w3c for pre-standards discussions

dezell: Is a contract something that consumes a verifiable credential (e.g., a pre-condition), or is a contract the basis for a credential?

allen: Works both ways

Manu: There's a gov org interested in this; can't remember. Also internet governance forum?

Allen: Permissions people interested as well.

dezell: You have both metadata about contract and event trace on the ledger
... for each one, do you see that as being something an attorney would do?

Allen: The bifurcation you identify could be seen as "testers" v. "specifiers"
... in a way, the metadata / contact is of interest to lawyers...with their tester hats on

<burn> Here is one of probably many books on this topic: Blockchain and the Law: The Rule of Code. Aaron Wright is at ConsenSys and would definitely be interested in a workshop that actually cares about the legal framework rather than just the technology

Kim: We could do a typical rebooting timeline

dezell: Payment Request API does not create a contract, it starts steps necessary to fulfill a contract.
... you could have "contract on demand"

Allen: I haven't framed applications that way.

<burn> To add, Kim also mentioned that Rebooting attracts mainly tech people.

Allen: bisimulation proofs involve a comparison between request / offer pairs and evaluate whether a match is sufficiently good

Ken: Thank you for this presentation. I understood very little of the presentation but I am a lawyer on the business side of American Express
... if I put my lawyer hat on; I understood a lot being about execution of what has been agreed to by parties
... the biggest pain points I see from a browser and payments ecosystem perspective is the ability to do near real-time agreements with cardmembers and merchants
... real time contractual agreements among parties that do not have pre-existing relationships is a challenge

Allen: Our poster child application is baggage handling
... we know how to spin up a contract for every bag
... takes about 1/10 second
... we do this in relational databases; don't know what time would be required in the blockchain
... but we have in mind these one-time contract scenarios

Ken: We have that challenge in the US payments ecosystem - could be 20 or more parties involved in a traditional payment
... banking relationships, acquiring relationships, networks, and other third party carriers
... Liability shift is another issue that's important in the payments industry

DavidChadwick: In the baggage use case, the players are known in the industry
... but the use case for payments is different; merchants may pop up at any time (and may or may not be trustworthy)
... there are opportunities for enrollment in transactions

Ken: Would be greatly valuable to accelerate acceptance

Allen: Baggage handling is among a known set of players, but those players have providers who are not known a priori.

Dezell: credentials can allow you to play a role in a contract in real time

Joe: There is also work on object capabilities that is relevant; a contract should be able to create an object capability

Next meeting

<scribe> ACTION: Ian to schedule a 19 November, at 10:00 ET call

Scribe note: At the end of the day the participants preferred informal discussion to the scheduled agenda. Therefore, some of those present elected to meet the next day to discuss merchant adoption and industry priorities. As a result, at least some of the discussion that had been anticipated for 19 November has already taken place. The Chairs will announce the date of the next meeting within 2 weeks.

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/10/29 13:09:31 $