Warning:
This wiki has been archived and is now read-only.
View source for Main Page/FTF Feb2016/Blockchain and the Web

← Main Page/FTF Feb2016/Blockchain and the Web
Jump to: navigation, search
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in one of the groups: Users, 106, 73816-chairs.
You can view and copy the source of this page.


= Blockchain and the Web =
== Timing ==
* (15 mins) Erik introduces goals and key topics
* (5 mins) Initial observations of what might be needed from the Web
* (30 mins) Discussion 
* (10 mins) Next steps
** Are there groups with whom we should be working?
** Are there ideas we need to elaborate (e.g., in a task force)?

== Goals ==
* Understand how blockchain might address use cases that are addressed today using web technology. In particular, use cases that are close in scope to what the IG/WG are discussing.
* Begin to identify what would we need from the Web in order to support blockchain solutions to those use cases (e.g., we need API to access secure element)?
* Non-goal is to have an introduction to Blockchain or bitcoin; we hope to provide pointers to useful intro material before the meeting.

== Topics ==

=== Payments===
* Peer-to-peer payments
* Micropayments, such as $0.05 to read an article, "today" would require a P2P transactions because any 3rd party payment transaction, like a credit card or wire transfer, fees are more costly than the content.
* Wallets
** Current trend are toward physical wallets in the form of hardware (ie a dongle or mobile phone). Secure element can be the secure tunnel to cloud or Blockchain based wallet.
 Secure element can be the secure tunnel to cloud or Blockchain based wallet.

=== eCommerce===
* Receipts
** Message choreography between a public ledger and permissioned ledger will allow more sensitive information, such as purchase histories, to be placed on a non-reversible permissioned ledger with linking to the actual transaction on a public ledger.
* Coupons
** Coupons can be distributed electronically and bound for 1 usage.
** Allows a decoupling from the payment instrument to coupon holders. Secure elopement can be the gateway to anonymous identity metadata or extreme privacy.

=== Licensing Ledger ===
* Call with Andy and Justin of Carl Fisher revealed the need for a more flexible content licensing model between the web as a delivery channel and the content of the web.
** Many times for sheet music and books artists practice via reading on their electronic device(s).
*** Perpetual license of the music for the 1 device.
*** Multi-device licensing with different fee structures.
**** This is important because music glyphs are engraved. Different device resolutions will require a different licensing because the glyphs are customized for the device resolution.
**** Attempting to reflow the glyphs for different screen resolutions doesnt work.
*** Online reading of the music via the Web.
*** Linking data between
**** The payments details
**** The licensing ledger
**** licensed devices.
** Printed music needs to be separately licensed.
*** Artists always want printed music for performances.
*** Artists sometimes want printed music to take notes on the music.
*** reprints in the event of lost or damaged content
*** Bulk print licensing for performances, concerts and choir's
** Special Licensing Needs
*** For large performances, such a concerts and quires, we physically ship "rental" music sheets. We require the sheet music to be shipped back to us after a predetermined date. This is very expensive and inefficient. Would be much more efficient to "time license" an electronic format for 100 prints and water mark with an license expiration date. QR code with link back to the license ledger.
*** Various use cases surrounding "time based" licensing like
**** User wants to get a trial license on their electronic device.
**** Free content licensing for subscription members.
** A licensing ledger would provide us:
*** Empower more self-service licensing models like yearly reprints, ownership for life of device, ownership for life of the individual.
*** Soft linking the license of the content to the ledger. Current approaches are hard license approaches where the licensing is embedded in the content.
*** Relicensing of the content without having to reissue the content.
*** Direct tracking of licensed content for devices and printed media.
*** Direct user commissions for referrals. Example: Money or free choice of a licensed content.
*** Relicensing of 2nd party content to 3rd parties. Example: Concert and Quire
*** Certifies Professors can directly license the content to their "current" students for the duration of the class.
*** Tracking of & direct payment of commissions for 3rd party re-sellers.
*** Direct 1x1 coupon issuance to the individual without the need for a 3rd party.
*** Dynamic licensing between the electronic format and a license ledger provides us a lot more "self-service" licensing options
*** Creation of currently unheard of licensing models like licensing of all content from one particular artist or bulk licensing to a group of individuals.

=== Other ideas potentially of interest to W3C===
* Content protection / licensing (of course with privacy protection layers)
** Content licensing and data brokering can be bound as a verified asset between the purchaser and the content provider.
*** Possible bindings included:
**** Content licensed to the secure element (aka the device)
**** Content licensed to a cryptographic biometric identifier (once again secure elements, mobile device sensors, FIDO dongles plays a critical role)
**** Region codes and other geographic bindings
**** Content rentals and other time based licensing
**** Usage based licensing like 5 prints of a 3D printing schematic, 3 plays of a movie, 1 free play of a song, 1 print of sheet music.
** Better persistence of indication of rights (e.g., what happens if company using live data goes out of business?)
* Identity
** In Capital Markets, Identity isn't just about "what you know" but also "when you knew it".
*** Identity assertions, once extracted out of the Blockchain must be invalid, considered compromised, or at-a-minimum a very short time-to-live. Some data values, such as proofs of a user’s identity, must be considered fresh to have any value.
** Identity isnt just about ontology (data structure of user verifiable attributes) but its also about how the environment influences that information. User privacy, court auditors, law enforcement, international laws all apply pressure on the environment and requirements for access to user verifiable attributes.
** At its simplest form, Identity over the web is about combining authentication and secrecy techniques to create a “Privacy Friendly Identity & Data Management”.
** W3C has initiated a series of steps to allow self-service option to address privacy friendly identity management over the web. I am not saying the W3C has solved identity but the Web and the Browser will certainly be the origin and initiator of message sequences containing assertions about Identity:
*** Authentication:
**** https://w3c.github.io/websec/web-authentication-charter
**** Device is used as a "re-authentication" mechanism. Initial KYC processes and device enrollment may occur at an institutions secure enrollment facility.
*** Authorization, Access Controls, and Secrecy of the shared information
**** https://w3c.github.io/websec/hasec-charter
**** Hardware, in possession of the user, can be used:
***** Embed access controls to the data in the data itself, enforced via hardware cryptography from the point of origin. Since access controls travel with the data, the data is secured from cradle to grave.
****** Examples: Age, Financial Identifier’s, National Identifiers, Certificates, Qualifications.
***** Generate one-time, time limited, personal attributes that are bound between the origin and destination. These personal attributes will not be usable outside the context for which the identity sequence was initiated.
***** Geolocation of the user to allow proper geofencing of transactions, access to users personal data.
** W3C is following the trend of "Hardware as surrogate for the Identity". Ultimately the assurance of a user’s identity will come down to the capabilities or limitations of the user’s hardware device.
*** Example: The secure element of a user's phone, unlocked via biometrics or behavioral analysis, acts as the surrogate for the users identity. Devices are enrolled with the service provider.
*** Biometric’s are a capability of a users hardware, not the web. Biometric matches occur on the users hardware and should never be sent across the web. Users biometrically enabled hardware is enrolled as an authentication and authorization device with the end service provider.
** Blockchain is certainly NOT the solution to Identity as its too far from the point of origin of the user. However Blockchain uniquely solves 1 problem that has been eluding Financial Services for many decades, non-repudiation. If you use the above W3C specs as a tunnel/entry-point to the Blockchain you can put user assertions & claims on a public ledger yet keep the access controls to that information “In the users pocket”.
*** Possible Example: Government regulators can see that "Erik Anderson" executed a transaction and the results was written to a non-reversible ledger, but the keys/access-controls to the data disclosing the details of what "Erik Anderson" did in in my pocket. This allows the creation of a Privacy Friendly Identity & Data Management.
* Voting
** If you combine Identity with the Ledger this will prevent double voting and secure the data against unauthorized access by 3rd parties. You can anonymize various attributes of that data to allow useful statistics without disclosing privacy. 
* Security
** No significant security concerns since security & privacy of the contents on the Blockchain will have a great beginning via the above 2 W3C specs. A couple of notes though.
*** Its unfortunate that the Blockchain community don’t realize there is not one encryption algorithm to address the masses. When it comes to these mathematical structures & algorithms most major foreign nations take a open standard algorithm and make tweaks + modifications to the algorithms as a countermeasure to address their nations security concerns. Penetration of and attempted sabotage of various algorithms by known government agencies is still a daily occurrence.
*** Interestingly enough those government agencies has warned the industry to move to quantum-resistant algorithms.
* Regulatory Insight and Oversight
** Regulation, in a nutshell, is about the movement of and insight into information. Regulation and Blockchain is about analytic's and intelligence of content before and after data is written to the ledger.
** Insight: A public ledger, with the appropriate layering of privacy friendly mechanisms, can be used to also allow access to various anonymous statistics that governments uses to measure "economic health".
*** Example: Demographics, housing, International movement of money, spending habits where consumers switch from 2% milk to powdered milk, etc.
** Oversight: There exists many instances where Regulatory authorities have legal oversight of the movement of value. In these cases, allowing consensus algorithms with regulatory "veto" power over those transactions provides the regulators with the tools they need.
*** Note: This is a concept I have been pushing to put the “regulations in the code”. Regulations can be automated with far less cost and slower human involvement. This will directly reduce the amount of regulatory arbitrage & hand waving those authorities utilize.
* Wallet
** Current trend are toward physical wallets in the form of hardware (e.g. a dongle or mobile phone itself).
** If you combine the 2 W3C specs above with a public ledger you can truly create a digital wallet since the contents of the wallet are secure regardless of the mechanics surrounding the wallet storage. Secure element can offer the privacy and access controls to a cloud or Blockchain based wallet.
* Financial services more broadly
** Since the 2008 financial crisis, twenty of the world’s largest banks including JPMorgan, Citibank and HSBC have paid over US$235 billion in fines. Interestingly, the majority of the fines derived from the banking system’s inefficiency and failure to keep track of previously "verified assets". Example: sold mortgages, insurance products, collateralized assets, etc. Even debt obligations are collateralized, bought and sold.
*** There is immense value to an immutable permissioned public ledger utilizing Privacy Friendly Identity & Data Management. Auditors, compliance officers, regulatory authorities can do their jobs without all the Legal & Regulatory arbitrage that occurs today.
* Compliance
** Compliance and Blockchain is really about analytic's and intelligence of content before and after data is written to the ledger.
** Compliance, as it applies to the Web, is 

== Blockchain background ==

[[File:Block chain for the web.png|Blockchain and the Web]]
[[File:Identity_process_diagrams2.pdf]]

Note: We don't plan to cover background during the meeting.
* A ledger that generally runs in a hostile environment like the public internet
* It uses cryptography to try and solve identity and ownership problems in this public environment
* It uses cryptography to 'try' and automate business processes to reduce settlement latency to accelerate the value of money
* Assets are on and managed on the ledger. Off ledger interactions are considered legacy, slow, and inefficient.
* People use blockchain to manage assets (for Stock trades, payments, swap trade, currencies, bonds & coupons, corporate debts, etc).
* NOTE: Blockchain was born of Bitcoin, not the other way around. There are several very successful Bitcoin based companies but, once again, Bitcoin is the asset not the technology.
* There is no privacy, all transactions are on this public ledger and all parties can see those transactions.
* Transactions are absolute, there is no reverting the transaction. Chargebacks/returns are a business process because the ledger cannot be reversed. You must initiate a transaction back to the originating party.
* Current DLT Identity & Data security mechanisms is 'relatively unused' cryptography built for financial services in 1990's. These mathematics has a certain lifetime because computers and distributed calculations are getting faster & more efficient. NSA warns the current cryptography is not resistive to quantum computer attacks, 5-10yr max additional lifetime, target window 2021-2026.
* Utilizes a network-wide distributed consensus algorithm without a central authority. Lots of work is in progress to allow a more permissioned consensus approach allowing a central authority to issue new assets on the Blockchain, trusted nodes to determine consensus if a transaction should settle, yet allow a legal/regulatory/compliance-officer veto against the final settlement.
Observations:

== Initial Observations ==
* Web API access to the secure element. Secure Element may be in the form of a dedicated secure element for the device or in a portable form like a Yubikey.
** An open API to write application specific "content blobs" to a ledger.
* Trusted UI for human viewing of sensitive data?
* Encryption is not Regulatory friendly. Most logical approach would be a rules based engine that applies the cryptography prior to the data leaving the users control.
* Semantics is not enough. We don’t need yet another data modeling language. We keep reinventing data modeling in different syntax over the last 20+ years. Financial services information needs are far more dynamic than can be codified on a ledger, captured in an API, or achieved by passing around signed JSON blobs.
* To find our way forward I suggest we look to the past for some answers. In particular W3C’s past.
** https://www.w3.org/2002/ws/chor/
*** The Web Services Choreography Working Group did a lot of great work that was before its time.
*** Like most cutting edge software research projects this failed to find developers willing to take up the challenge. There is often disconnects between cutting edge research and practical implementations. Developers instead took a semantics approach vs pragmatic.
*** A few observations about CHOR (pragmatic approach vs semantics)
**** Language for conversations not data semantics
**** Description language not engineering execution language
**** Pragmatic behavior overlays semantic structures.
**** multiparty communications
**** business protocols
**** Models conversations & scenarios
**** How environment interacts with ontology (Regulation, Legal, Law Enforcement, Privacy, International Laws)
**** prescribed scenario of interactions
**** Processes of information exchange
**** International, domestic, and regional specification to local runtime verification
**** A good beginning to provide a programmable regulatory & legal mechanism for the movement of information
**** role-to-role ordered messaging
**** conversation delegations
**** safely combining dynamically and statically verified endpoints within conversations
*** CHOR may not have found a lot of uptake but its cutting edge research and development haven’t stopped. Some of those folks stayed focused on solving the pragmatic needs of complex information systems.
*** If you combine the 2 W3C hardware specs + Blockchain + CHOR you can create the mathematical enforcement of a design-by-contract framework to address dynamic business behaviors.
Return to Main Page/FTF Feb2016/Blockchain and the Web.
Retrieved from "https://www.w3.org/WebCommerce/IG/wiki/Main_Page/FTF_Feb2016/Blockchain_and_the_Web"
View source for Main Page/FTF Feb2016/Blockchain and the Web

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Navigation

Tools
