<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.
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)
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.
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
[Demo]
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
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).
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: 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
[Bitcoin]
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
[Identity]
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:
[Applications]
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
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
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
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
<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
<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.