4 challenges of shared processes managed by blockchain

Blockchain is already disrupting industries and bringing trust to scenarios where it was previously complex to implement.
Many of these solutions transfer data or assets between network members, but each scenario also represents a process between organizations.
For example, the journey of a shipping container is made up of hundreds of requests, approvals and document transfers. For a letter of credit, the blockchain solution is a shared business process. The benefits of a solution depend on how much a blockchain can improve these business processes. Benefits increase with the rise of business-network thinking that also increases trust. This makes radically improved ways of working possible.
Let’s take the example of health records on a blockchain. In the future, patients will control how their medical data is shared between healthcare providers, testing labs, and pharmaceutical companies. Currently, each organization stores its own data and manages its own processes.
An electronic health record (EHR) stored on a blockchain would securely share only the data that each party is permitted to see. Adding new test results to the record might automatically schedule an appointment with the patient depending on the test result. Finally, once the appointment is completed, the notes and follow-up actions are added indelibly to the EHR for future reference.
Every blockchain project contains business process change. This could mean an IT change to integrate a system with a blockchain, or, in more transformational solutions, the change is much greater. Some completely change business models or create new ones which can only exist with blockchain. For example, an insurance company could automatically pay claims when the consensus is that an event occurred.

Traditionally, processes are centralized on a private platform that is internal to an organization. Even in scenarios where processes are shared, each network member needs to allow others to access their private platform or delegate management of the process to a trusted third party (for example, in securities settlement). In an “interorganizational process” the process flow is choreographed by the code that runs on the blockchain. Control is handed over to process participants to complete tasks depending on their roles. For example, only a lab can submit test results and only care providers can hold appointments with patients.
However, interorganizational processes pose challenges. Some are familiar, some are new:

Why should some processes be shared and others be private to an individual network member?

How can a network member avoid losing visibility or control of who is doing what and when? Changed processes must improve client trust, satisfaction, cycle times and consistency of experience in a decentralized environment

How can shared processes be automated in such a way that they can be governed by lawyers and decision makers, without duplication and to be fully compliant?

What should network members do when something unexpected happens? Who should handle bugs in the contract, disputes, errors and rework, contract changes etc.?

In our next post, we’ll discuss some methods for addressing these challenges.
Learn more about IBM Blockchain.
The post 4 challenges of shared processes managed by blockchain appeared first on Cloud computing news.
Quelle: Thoughts on Cloud

Google Cloud services are switching Certificate Authority

By Adam Langley, Software Engineer

Earlier this year, Google announced that we had established Google Trust Services to operate our own Root Certificate Authority on behalf of Google and Alphabet. Preparations are proceeding apace and customers that rely on Google services—including Google Cloud services such as Compute Engine, Gmail and others—should be aware that Google will soon begin using a different Certificate Authority (CA). We expect this to have no impact for the vast majority of customers.

Google commonly uses TLS (previously known as SSL) to secure communications between Google services and our users. As part of TLS, a server is required to provide proof of its identity in the form of a certificate that’s signed by a CA. Google has long used certificates ultimately issued by the CA “GeoTrust.”

In the coming months, Google will begin using the GlobalSign R2 CA (“GS Root R2”). As it’s a well-established and commonly trusted root CA, we expect minimal disruption to clients. However, for TLS clients that operate with custom root stores, we recommend that customers and application vendors ensure that their applications trust at least our minimum root set (PEM file).

The Google Trust Services home page contains links for customers and application vendors to test support for Google-operated roots, including GS Root R2. However, because we may use other roots in the future, customers should use the aforementioned root set and not simply the specific roots currently listed there.

More generally, a reasonable root set is not the only factor in ensuring that TLS clients continue to function over time. TLS clients should also meet these requirements to ensure minimal disruption:

Support for TLS 1.2.
A Server Name Indication (SNI) extension that contains the domain that’s being connected to.
Support for the cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 using the NIST P-256 curve (a.k.a “secp256r1”) and uncompressed points.
At a minimum, trust the certificates listed at https://pki.google.com/roots.pem.
Support for DNS Subject Alternative Names (SANs) by the certificate verifier, where SANs may include a single wildcard as the left-most label in the domain name.

We’ve been working hard to ensure that the transition to a new CA is as smooth as possible for users of our services. Feel free to reach out to us with questions or concerns: Google Cloud Platform | G Suite.
Quelle: Google Cloud Platform