What you could build: intended application patterns

Development status: Overview — The application patterns in this section are intended uses that rest on capabilities that are planned or being explored. Where an experimental implementation of an underlying capability exists, it is internal and simulates the confidentiality features these patterns depend on. None of the patterns can be built on Cubane today, and nothing is publicly available for live use.

Before you read: What Cubane is designed to do.

What kinds of applications is Cubane intended to support, and what are the boundaries? This section answers that question through six application patterns: recurring kinds of application that the design intends to support. This page introduces each pattern with its status label and a one-line purpose, helps you choose the pattern page that matches your need, states the limits that apply to every pattern today and points to the capability pages that the patterns rest on.

How to read the pattern pages

• A pattern is a recurring need, not a product. Each pattern page covers the problem, the intended outcome, the parties involved, the current status, the boundaries and the open questions.
• Scenarios, not solution designs. Pattern pages describe situations in which a pattern would apply. They contain no integration designs, service terms or performance figures.
• Capabilities are explained elsewhere. A pattern page never defines a capability; it links to the capability’s primary page instead.
• Each pattern has its own label. Status labels differ from pattern to pattern, and no pattern is supported end to end by the experimental implementation. Labels describe maturity, not availability; see Documentation conventions: status labels, dates and reviews.

The intended patterns

• Processing sensitive data with verifiable results — Being explored. An application would keep selected data confidential while others could still check the results that depend on it. Encrypted processing is only simulated in the experimental implementation.
• Sharing selected results with auditors and partners — Being explored. Data owners would decide who can see which data, including time-limited access for an auditor or a partner. The experimental implementation holds no access-controlled data.
• Organisation workflows with shared approval and custody choices — Being explored. Several approvers for sensitive actions, a choice of how signing keys are held, and starting profiles, brought together in an organisation’s own workflows.
• Cross-border payments and remittance — Being explored. An early-stage target use case. No remittance service exists.
• Using outside data in confidential applications — Being explored. Confidential applications would use outside data feeds. Several questions remain open, and nothing of this kind exists today.
• Use-case profiles — Being explored. Opinionated starting configurations to help teams choose confidentiality and performance settings for a common use case. No profile is defined yet.

Choosing a pattern by need

Start from the statement that sounds most like your situation:

• “Our data must stay confidential, but others must be able to rely on the results.” Read Processing sensitive data with verifiable results.
• “An auditor or partner needs to see part of our data for a period.” Read Sharing selected results with auditors and partners.
• “Several people must approve sensitive actions, and we must decide how keys are held.” Read Organisation workflows with shared approval and custody choices.
• “We are exploring cross-border payments.” Read Cross-border payments and remittance.
• “Our confidential application needs data from outside.” Read Using outside data in confidential applications.
• “We want a recommended starting configuration.” Read Use-case profiles.

Needs often overlap — an application that processes sensitive data might also need to share selected results with an auditor. Read every page whose statement fits.

Limits that apply to every pattern today

• Nothing is publicly available. There is no public network, SDK or tooling with which any pattern could be built, tested or piloted. See Development status: what exists today and what does not and Tools, SDKs and wallet availability.
• No confidentiality protection today. In the experimental implementation, confidentiality and proving features are simulated or switched off, so it provides no confidentiality protection. A pattern that depends on confidentiality is therefore not demonstrated by the experimental implementation.
• Some information would remain observable. Even with confidential processing in place, some information about activity would remain observable to others. See What remains observable.
• Intent, not commitments. Patterns describe intent. Their scope may change, be deferred or be withdrawn, and no dates are given.
• Compliance. What is and is not claimed about compliance is set out on Compliance position and data-protection intent, not on the pattern pages.

What the patterns rest on

Pattern pages link to capability pages rather than repeating them. The capability pages they most often rely on are:

• Confidential computation
• Visibility controls and selective disclosure
• Approving actions: authority and multi-party approval
• Custody options for organisations
• Confidential jobs: tracking, cancelling and retrieving results
• Fees and cost estimates

Trust assumptions are described on Trust assumptions and responsibilities by participant. The user-level model of participants, transactions and confidential jobs is in System model: how Cubane is intended to work for its users.

Assumptions, trust and limitations

• Every pattern depends on capabilities whose design is unsettled, so any pattern may change as the design matures.
• Organisations would remain responsible for their own policies — who approves which actions, how keys are held and who may see which data — and for their own legal and regulatory obligations.
• Pattern descriptions are not evidence that the platform suits any specific workload. They describe intent and should not, on their own, be the basis of a decision about fit.

Not yet available, and how this page will grow

Once the underlying capabilities are implemented, enabled and publicly released, pattern pages would add prerequisites, versioned references and labelled illustrative examples. A new pattern would be added to this section only when the capabilities it rests on are documented at summary level on their own pages, and any such change would be recorded in the Documentation change log. Further technical reference is not yet available.

What this page does not claim

This page does not claim:

• that any pattern can be built, tested or piloted on Cubane today;
• that Cubane suits any particular workload or organisation;
• any performance, capacity or cost figure;
• any legal, regulatory or compliance assurance.

Anything not stated here as available should be treated as unavailable.

Related pages

• Processing sensitive data with verifiable results — the pattern closest to the platform aim.
• Sharing selected results with auditors and partners — selective, time-limited sharing of data with reviewers.
• Organisation workflows with shared approval and custody choices — approval, custody and starting profiles together.
• Cross-border payments and remittance — an early-stage target use case.
• Using outside data in confidential applications — outside data for confidential applications.
• Use-case profiles — intended starting configurations.
• What Cubane is designed to do — the aim that the patterns express.

Glossary

• Application pattern
• Verifiable result
• Selective disclosure
• Multi-party approval
• Custody
• Use-case profile
• Outside data feed

References

No approved public references yet.