License: European Union Public License 1.2
Demonstrate how OCA core components interact with each other.
EUPL 1.2
We have distilled the most crucial license specifics to make your adoption seamless: see here for details.
See https://oca.colossi.network page.
In the Spec, the Meta overlay is defined as:
A Meta Overlay defines the descriptive information about a schema or form. It is used for discovery and identification and includes elements such as form name and description.
In the Excel to OCA Bundle converter, it appears that only Name and Description can be defined, and only one value is picked up.
Questions:
I'm trying to understand why the OCA Bundle is a set of JSON files in a ZIP file vs. just a single JSON file that contains a set of overlays?
For example, when we use in a piece of software (say, a wallet), we want the JSON to be in this form, which is a single JSON file that is:
{
"capture_base": {
"type": "spec/capture_base/1.0",
.
.
.
},
"overlays": [
{
"capture_base": "EfeQBz5tyC0gett-ETgkg4pkxBwwuQoeYsT-9Nt0cNsc",
"type": "spec/overlays/meta/1.0"
.
.
.
]
}
We currently plan on have the code that retrieves a bundle convert it to the single JSON structure format for internal use. Is there a good reason to pass it around as a zipped set of JSON files and leave the JSON assembly to later in the process?
In looking at the OCA Spec 1.1.0-rc, I don't see how each overlay is cryptographically linked to the capture base. Is that part of the spec? I think it is necessary that it be linked, and the technical approach needs to be specified to enable verification. For example, what is canonicalization scheme being used?
Does the scope of the spec cover only that there are standalone overlays that link to a capture base, or does the spec. also define how a set of standalone overlays can be combined together -- e.g. as a zip file or as a JSON structure?
We need a way to have a number of "Meta"-like entries that are language agnostic. As currently defined in the OCA Standard, and managed in the OCA Source spreadsheet, "Meta" entries (name/value pairs) are multilingual and thus the names are duplicated for each language. However, there are a number of values for Meta names that are the same across all languages. How can we manage that?
Two ideas for that:
I think this is a generally useful feature and belongs in the OCA Core. In the Aries community, we could address it using a custom overlay that is defined within the community.
Example use cases:
We have come across scenarios when there are multiple levels of data type, encoding and formats, and I'm wondering how best to express those in OCA. Here are some examples:
It seems like there is flexibility in the combination of overlays (data type, encoding, format), but I'm not sure the general concepts of how to apply them. Are data type and encoding constrained, and everything else should be in the format? If so, how should format be used?
In addition to base64, multibase should be added to the applicable encodings.
In a wallet holding credentials, we will likely have at least two credential layouts that combine layout (colour, perhaps background image), text (name of credential type - multilingual), issuer name, attribute labels and data. The ones we know about:
How does one specify multiple credential layouts with a type associated with each so that the display tool can know when to display one or the other?
In the OCA for Aries RFC (currently a PR), we are planning to have an Aries-specific overlay. Is there any guidance on what the overlay type should be? We are thinking of using the following type:
{
"capture_base": "EPMaG1h2hVxKCZ5_3KoNNwgAyd4Eq8zrxK3xgaaRsz2M",
"type": "aries/overlays/branding/1.0",
"logo": "data:image/png;base64,iVBORw...",
.
.
.
Any guidance would be appreciated.
We have a requirement that an OCA Bundle be signed by the publisher. In our case, the publishers will use a public DID to sign the OCA Bundle as the publish it. Is there any plan to include signing an OCA Bundle as being in the scope of the spec. If not, any suggestions on how to do that in a useful way? It would be really nice to retrieve a bundle that includes a signature in a standard way, so that the processing of the Bundle can include verification of the signature.
We will come up with a way to do that for our use case (e.g. for use by at least Hyperledger Aries frameworks), but I think the requirement is more broadly applicable.
We are considering a constrained way to define a credential layout. Basically, we want to declare some screen elements and then leave it to the item displaying the credential to assemble them into a layout. For example, an OCA Bundle publisher might say:
I'm getting a link to a presentation where we go over this.
Is it technically possible to use the "layout" overlay to set some data elements that a display engine knows about, but not provide detailed layout information?
Is that a good approach?
One of our concerns is providing a responsive display of the credential -- e.g. that looks good on both mobile and web. Is it technically possible to provide the "Swiss Passport" type detail that works across devices and display types?
OCA presentation layer is one of the third fundamental features of OCA. The two remaining are data harmonization (including any third party process to achieve harmonization, ie. transformation) and context preserving data capture. This triple enables everyone to preserve capturing context of the data, have the consistent data and finally present it on the screen if needed. Not every data requires presentation on the screen and usually only this that was captured from humans. In other words if one party fulfilled the form, the other party may want to see it on the screen. When data doesn't need presentation in most cases will be captured by machine, ie. an IoT sensor that measures environmental data. Data captured in such manner will require unified form for further processing/data mining/predictive maintenance, therefore harmonized data is they key to achieve it.
OCA presentation layer enables to visually see the captured data in the most human friendly way. Either this is mimicking real world cases to digital world (ie. any type of credential) or just a nice way of presenting data on the screen, it is always dependent upon device and the underlying technology used for actual presentation. Being device and technology agnostic in terms of presentation is very difficult to achieve. Many devices and technologies exist for information presentation while none actually enables a unified way of doing so. The presentation problem is known since decades and many tried to unify it in the past. However, the fact is the industry never reached even a standard of how to define information presentation on the screen, not mentioning cross device or cross technology portability. Is this a gap that the industry didn't notice? No, this is a difficult problem to solve.
Any presentation is device and technology dependent. Devices come in various resolutions and screen sizes, usually biased to some particular technology that can be used for presentation. Therefore any approach that would address agnostic-ism to device and technology must be merely about layout, so about spatial orientation or how various pieces are located on the screen (or part of it). A good example of how to think about it is this tree:
Linked from https://docs.flutter.dev/development/ui/layout
Any layout is inherently a tree based structure that consists of elements, that are displaced upon the parent element. A syntactic sugar, so the rows and columns concept enables better spatial orientation. The current layout overlay is implementing this concept as follows:
...
- type: row
elements:
- type: col
elements:
- type: label
name: attribute3
...
Layout overlay shall provide only spatial orientation of the elements on given area and at the same time stay technology agnostic. The current layout overlay requires css attribute and therefore is not technology agnostic.
Worth to recap the fundamental assumption that all the overlays implement: they are deterministic, actually the whole OCA bundle is. Deterministic OCA bundle is in other words self-encapsulated and nothing can be injected in runtime. In this sense all the overlays are inherently made in stone. Deterministic OCA is crucial characteristic for proper governance.
To achieve such kind of agnostic-ism, current layout overlay must remove any technology specific behavior and become template overlay. Where there's a need of technology specific behavior, new type of overlay has to be defined: layout overlay. Assuming ZIP as OCA bundle, the following would be a part of the meta file:
digest: template.credential.<1024.yml # template overlay
digest: template.credential.1024-1280.yml # template overlay
digest: layout.credential.web.<1024.yml # layout overlay that reuses credential.template.<1024.yml
digest: layout.credential.web.>1024-1280.yml # layout overlay that reuses credential.template.1024-1280.yml
digest: layout.credential.flutter.<1024.yml # layout overlay that reuses credential.template.<1024.yml
digest: layout.credential.react-native.<1024.yml # layout overlay that reuses credential.template.<1024.yml
A dependency tree among overlays would look like:
.
├── template.credential.1024-1280.yml
│ └── layout.credential.web.>1024-1280.yml
└── template.credential.<1024.yml
├── layout.credential.flutter.<1024.yml
├── layout.credential.react-native.<1024.yml
└── layout.credential.web.<1024.yml
Layout/template overlay metadata consists of:
credential) [required],react-native) [required],<1024) and driver name (ie. flutter -- only layout) [optional -- if not defined, applied for all cases].This is a proposal and can be discussed further. What's important is the clear distinction per device and technology.
In all cases YAML is preferred as it is the simplest descriptive language for defining behavior.
Layout overlays merely inherit from template overlays the spatial arrangement and add technology specific flavor that is required to render them properly, using given technology.
These assumptions guarantee flexibility while preserving the determinism. There can be any number of template.xyz.yml as well as layout.xyz.yml, each serving desired purpose or spatial arrangement, including proper logo, background color and so on. This is always finite number of cases(overlays), even across various jurisdictions or countries. Since there are multiple of them, it is up to the client to decide which one to use in given use case (according to device resolution or the underlying technology).
The drivers that are responsible for proper rendering can be implemented externally for given technology. Whether this is Flutter, React Native, PDF or WEB, it is up to the driver to present the layout properly. Presentation, so the driver, is optional to the OCA core and therefore all the rendering drivers are optional.
The template overlay defined above provides only a spatial arrangement. Neither components nor styling are defined on this level. This is only an agreement how assets provided via layout overlay must be arranged within given area.
Layout overlay adds proper look and feel to the template overlay.
Whether layout overlay is part of OCA bundle is governance dependent. In cases where issuer didn't impose any particular rules of how to present his data, but merely provided minimum amount of assets that shall be used, ie. this case, layout overlay is outside OCA Bundle.
As we in the Hyperledger Aries project look at how we can apply OCA to solve our rendering issues, we'd like to look at some adjustments to the OCA Source Excel file being used. We really like the idea of managing the OCA source data in Excel, as it is very easy for our contributors/translators to use, but we'd like to propose a couple of adjustments.
As a first draft, I've revised our instance of an OCA Excel file we already use, to show the changes I think we'd like to have. I welcome input from others on what else we should include. The goal is to not make this Aries specific, but to include features that we think any OCA producer/consumer would likely use.
Our schema, current format
Our schema, proposed format
The changes:
In parallel to the "template" overlay -- we need to define the template overlay to be either part of the OCA Spec, or an extension to the spec.
I welcome feedback and discussion on this. What is not appropriate? What is missing? Are there better ways to achieve the same result?
Data Entry Excel - dates that appear in the schema conformant section appear as Excel DateValue ( ) and not formatted according to an ISO specification (e.g. YYYY-MM-DD). Suggest that the date entry and associated format from the Data Entry tab is copied directly to the schema conformant section.
Also suggest that we remove protection from the 'schema conformant data' sheet. Data validation cannot ultimately happen within Excel - there are other tools that will do a better job. Instead, the Data Entry Excel should help researchers prepare for validation tools. The development to make Excel work with OCA would be too much.
The current format overlay doesn't defined the supported format for displaying date, it currently defines as
The inputted format value for this core data type MAY be a date and time representation as defined by ISO 8601, a standard for the worldwide exchange and communication of date and time-related data.
What are the accepted output/display format tokens? YYYY, MM, MMM, MMMM, DD, etc.
Should it also support any localized output format such as the one defined in Javascript/ES6: "full", "long", "medium", "short"
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.