Feedback - Visualization of Verifiable Credential with OCA Specification

[bj-ms]

This thread is for feedback, questions or general inputs on the new specifications for visualizing Verifiable Credentials in the wallet.
Link to the new specification: open-source-community/tech-roadmap/rfcs/oca/spec.md at main · e-id-admin/open-source-community (github.com)

[M-Wong]

One thing that I feel is missing from the OCA specification in regards with the Aries Branding Overlay and the Cluster Ordering Overlay is attribute aggregation.
The branding example defines the following primary and secondary attributes:

{
    "primary_attribute":"firstname",
    "secondary_attribute":"lastname"
}

In the Aries OCA style guide these two attributes are displayed as two separate text fields in the card layout.
Oftentimes it would make sense to display the full name as one text field, but right now that would require the issuer to include an additional attribute fullname in its credential and the capture base, so it can be used in a presentation overlay.
Maybe there could be an additional transformation overlay that allows attribute aggregation? Something like this:

{
    "type": "spec/overlays/template/1.0",
    "capture_base": "...",
    "attributeTemplates": {
        "fullname": "{{ firstname }} {{ lastname }}"
    }
}

In the OCA processing code, the fullname attribute value would be resolved by treating values inside the brackets as references to other regular attributes.
Then, fullname could be used as the brandings primary_attribute, while the Cluster Ordering Overlay could still use firstname and lastname separately in its clusters.

One issue I see with this kind of overlay, is that it either requires some overlays (e.g. the label or information overlays) to be aware of the new properties produced by this overlay, or that the capture base needs to include the aggregated attribute as well (which could potentially lead to conflicts if the capture base doesn't use the attribute type TEXT).

Is this a topic that was already discussed or needs to be considered for the specification (either the official OCA or the Swiss OCA one)?

[bj-ms]

Attribute aggregation is definitely a discussion that we have had and it comes down to the issue of creating dependencies between overlays.

I would argue that we would have to extend the definition of the Capture Base from the OCA specification rather than create an additional overlay because of the dependency issue. There is currently no way to define an overlay dependency or priority, and I would say that this is not the intent of the OCA specification.

Additionally, this could raise the question of what to include in the Capture Base. For example, how should we handle JSON pointers? Should they be in the capture base as part of the attribute name as currently defined in the specification, in a separate object in the capture overlay, or completely separate as an overlay?

And on the topic of Aries Branding Overlay, we mention in the Swiss OCA specification that it is up to the implementers to interpret the Aries Branding Overlay values.
This means that an Issuer won't be able to force a wallet implementer to have the primary and secondary attributes displayed on one or multiple lines.

We will take notes and this is definitely a topic to follow up on.

[mitfik]

Attribute aggregation

I think the problem need to be address differently. Attribute aggregation could have many meanings but if you properly approach the problem you don't need to deal with it. Generally speaking someone defines meaning of the data which needs to be put into the VC (does not have to be Issuer - see passport example where issuer is state by definition could come from ICAO) how it is displayed or presented can depends and this could be decided by different entity (e.g. state of the Swiss passport case).

The issuer could define how it should look like e.g. to display two attributes concatenated or derive value from multiple fields - like quite often national number is constructed from data of birth + gander + check sum.

The transformation which is happening here can happen on the semantic level or data level. Example of semantic level you can see here

The example comes from the data collection mechanism in health care but general idea is the same, you quite often need to bridge semantic between different standard and ontologies, transformation is simply consequence of it. In your case you are speaking about presentation but generally is same problem someone defined what we collect standard A someone else define how I want to display it standard B and the bridge can be done without loosing end-verifiability properties of the whole object which is crucial in VC

[M-Wong]

@mitfik Let me see if I understand you correctly. You say that the transformation can happen on a semantic or data level.
Data level means the issuer needs to include everything in the VC, although having the issuer transform and aggregate data in the VC doesn't seem logical because there will always be more use cases that aren't covered and it just increases the size of the VC unnecessarily.
On a semantic level means, those bridging the issuance and the presentation need to be aware of both what is specified inside the VC as well as how it should be displayed and apply the correct transformations to get from one to the other.

To me, OCA is supposed to be that bridge. In my mind, applying an OCA bundle to a VC outputs some kind of data structure that can then be displayed in whatever application is using it. But that presentation data needs a generic structure, depending on the presentation overlay and use case (e.g. credential list vs single credential detail) otherwise the application needs to handle every VC type individually.

Lets take the Swiss OCA Cluster Ordering Overlay as an example. The presentation for this overlay is pretty straightforward, it's supposed to display a VC as a number of clusters, each with a title and a number of attributes within. How those attributes are then displayed depends on their character encoding, format, etc. defined in the OCA bundle.

In the example, the address cluster contains the attributes for street, city and country. Without a transformation overlay, there is no way to display the entire address as a single field because the issuer (data level) does not specify it. I would either have to transform the VC payload itself or do some very specific handling of the output of the cluster ordering overlay to achieve that, which both seems counter-intuitive to me.

[mitfik]

Data level means the issuer needs to include everything in the VC

No it does not, transformation is applied after the issuing process. As you noticed Issuer in many case have no idea how it would be used in the future. Transformation is done on other side if Verifier, or wallet provider would like to see full_name instead of first_name and surname he would do the transformation. Having integrity and authenticity of every single object allows to do it in secure way, without compromising on the security.

On a semantic level means, those bridging the issuance and the presentation need to be aware of both

This is not true as well, presentation does not have to be concern of the issuer. We used to it because in analog world there is no other way, you get a paper and that enforce the "form factor" in digital world you can get payload digitally signed, and then you can have different presentation for blind people, for color blinded or someone who speaks extinct language. How he would see it does not mean that same way Verifier would see it. The presentation can be of course enforced but does not need to come from issuer of the credential. Which does not mean that cannot be secure by cryptography and be part of the VC (attached to the VC by trustworthy third party).

Lets take the Swiss OCA Cluster Ordering Overlay as an example.

What if issuer issue 8m credentials and then would like to change the grouping mechanism ?
What if one case it would make sense to group stuff in one way and in another use case just list all alphabetically ?
With this approach you enforce issuer to think about every possible combination which he would like to enable.
With layered architecture (as in OCA) you allow multiple stakeholder take care of it and swap stuff as you need after the issuance of the credential it gives you more flexibility. This is why OCA is layered architecture allowing to issue credential, simply you issue credential with capture base + bare minimum to encapsulate meaning/intention of the credential, and later you can add different layers (e.g. presentation, labels, information, conditional) per use case.

In the example, the address cluster contains the attributes for street, city and country.

Are you verifying presentation or credential? Presentation should be irrelevant for verification process.

[jurajsarinay]

I am utterly confused. OCA appears to be an unnecessarily complicated way to address problems you do not even have. You are building a wallet application to store digital credentials. According to the presentation from September, you seem to need some kind of style sheets.

The OCA is nowhere near (becoming) standard. The technical specification (if one dares call it that) mentions Layout Overlays and "specifies" them as a TODO. If you have to define the stuff yourselves anyway, why bother with the OCA to begin with?

The way a credential is displayed on user screens is necessarily independent of the way relying parties actually verify credentials. No relying party should care what a credential "looks like" on your phone. All the styling is only there to help users find a particular credential in the wallet. This is not even much of an issue, given a relying party should be able to request a particular type of credential. The wallet should know I need a driving licence (say), one should not really need to browse for it. A typical user will only possess a few credentials and will be well familiar with the content. How you choose to display or label one's date of birth is rather irrelevant. Most people are aware of their age.

The use of OCA is completely unreasonable. One might be tempted to think that the way you reason about styling is rather harmless. On the contrary, you introduce additional complexity and get very little in return. Unnecessary complexity is seldom harmless.

OCA may also have led you to pick up CESR and SAID. Neither of the two is a recognised standard, CESR is one abomination of a format nobody should use.

You have already decided to diverge from OCA, given the particular feature "adds no value". That is a good start indeed.

[bj-ms]

I think this is a good opportunity to clear up some misunderstandings.

The fundamental problem we want to solve is to find a generic solution for how to visualize verifiable credentials in the wallet (relying parties do not need the OCA bundle).
This means not only how a credential should look like, but also how the data should be interpreted.
A good example is when you are given a string. When you parse that string, we will not always know what it represents. It can be very useful to know that it is a data URL and that it represents an image.

OCA has some ideas that we think are relevant:

• Defining a finite set of attributes
• Applying specialized overlays to the set of finite attributes
• Integrity between filename and content of the OCA bundle
• Multilanguage support

In addition, there are efforts by the Aries project to use OCA to visualize Verifiable Credential, which we found to be a relevant option.
It made sense to base our specification on an existing technical specification and try to avoid creating just another specification.
We created the Swiss OCA specification because we felt the need to clarify points that were not clear enough in the OCA specification and to add or remove features that we felt were relevant.
We are also discussing with the peo in the Aries project if we can find a way to get to a single technical specification.

Also, the Human Colossus Foundation behind the OCA specification is aware of our work and we are trying to get as much feedback as possible for this use case.

To accomplish this task, I will try to summarize your feedback in the following bullet points:

• CESR and SAID are not recognized standards and would like to see them replaced by a standardized format.
• You feel that not all parts of OCA are necessary and suggest that we try to strip the specification down to the bare minimum and reconsider whether we still need OCA.

Can you please validate that I understood your feedback correctly?

[mitfik]

CESR and SAID are not recognized standards and would like to see them replaced by a standardized format.

I think everyone puts too much pressure on standards without focusing on solving real problem. Both CESR and SAID are IETF specs same as many other technologies which are in the wild some of them are well adopted like e.g. JSON schema but they never were even proposed as standards and approved by any SDO. On other hand there is plenty of standards proposed by various SDO which were never adopted. Suggest to focus on solving problem and picking something just because have a certain label.

The reason why CESR and SAID is used is because of their properties. OCA uses both because OCA is core technology of Dynamic Data Economy where data are in motion (cross-governance). It requires certain flexibility (e.g. cryptographical agility) and portability (content centric approach) to fulfill those requirements.

If you build VC which would operate in closed ecosystem without limited use cases probably you don't need such solution but if you thinking about designing infrastructure for use cases which you can't even define at the moment of building it you need think about general characteristics instead of use case specific.

Simply what if your credential would need to travel to different jurisdiction (between Cantons or even countries) where they could have slightly different semantic and in between you would have 30 different wallet provider where not necessary you can enforce them to adhere to same rules e.g. wallet on phone vs wallet on smart watch.

If you need only "presentation" solution probably OCA is not for you but if integrity, interoperability, portability and security of semantic and presentation is one of your concern then probably you won't find any other solution which does that. We could not find it this is why we build one.

[jurajsarinay]

Can you please validate that I understood your feedback correctly?

I hope so. I am convinced that OCA, CESR and SAID should be avoided.

[jurajsarinay]

Both CESR and SAID are IETF specs same as many other technologies which are in the wild

It is well known that people submit all sorts of nonsense to the IETF. That's why all the drafts contain the following useful disclaimer:

This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.

[pknowl]

@jurajsarinay - Thanks for your feedback. At this stage, the focus is less on convincing and more on addressing real pain points through collaboration and consensus. We’ve spent the last five years demonstrating the viability of decentralised semantics, and now it's about refining implementations already in the wild or the imminent pipeline. Let’s focus on how we can overcome any challenges you're facing and work together to streamline the process.

[mitfik]

Dear all,

I'd like to clarify a few points about the Overlays Capture Architecture (OCA) and its current development at HCF to help you better leverage it for your projects.

OCA - Overlays Capture Architecture was designed to capture and understand the context and meaning of information for further processing and portability, particularly in terms of interoperability and data flows. This means that when you receive a data package, OCA enables you to comprehend the context in which this information was captured and its intended meaning.

To ensure functionality across different jurisdictions, a critical aspect of OCA is its integrity. Everything within OCA is content-addressable through SAIDs (Self-Addressing Identifiers), ensuring the integrity of data irrespective of its source. This is crucial for maintaining cross-governance compatibility.

For comparison, consider the schema.org/person model. When you use this schema, you cannot be certain that the content it references matches your expectations. This ambiguity opens up potential attack vectors, particularly in the Verifiable Credentials (VC) space. For example, by altering the meaning of a schema, you could change the outcome of a validation process, such as the difference between "Are you allowed to enter?" versus "Are you NOT allowed to enter?" if a simple affirmative 'yes' is misinterpreted or maliciously modified.

Important to mention as well is that VC use case for OCA is relatively small and one among of many use cases where OCA shows it strength in space of data capture/collection and processing.

P.S. OCA follows dominant design - we build, we test and then if it works becomes de facto standard. Writing a spec or "standard" does not mean that is good or that everyone should use it. At HCF we have more practical approach.

now let's dive into details ...

[mitfik]

To better understand mechanics of OCA let's take a look on below diagram:

Notice the split between mechanics (pure meaning), presentation (how I want to look at it), and invariants (business logic). The split is simply comes from the need for flexibility and divers use cases where OCA is used. The split brings as well simple responsibility segregation into the architecture.

I would agree with @jurajsarinay that presentation (how credential look like) is irrelevant for the verifier and the verification process. If at all some verifiers actually would prefer to see it in a way that they expecting not how the user sees it e.g. German driving license, verified in China would required to look according to the chinese authority not as user have it on his phone.

Above split between mechanics and presentation allows you logically address those problems. OCA by definition allows you to have multiple stakeholder to own seperate layers of the stack. This why if you need to have different presentation it can be created, linked and presented according to the jurisdiction where you verify not how the issuer issued it. But I would argue that in the future presentation would be irrelevant anyway, as what matters is the prove that credential is there and it belongs to you. I get that transition phase required to still doing stuff which people are used to but I am pretty sure we would get over it after some time.

[mitfik]

Being more practical, OCA stack already have mechanics and presentation implemented there are use cases where presentation is used to show credential or even more complex digital forms (for capturing) think of presentation as a specific view on the data structure which is in mechanics. Proposed branding overlay from Aries, can be easily replaced with that approach already that would cover topics like:

• styling, assets, static content (all content addressable)
• responsive design - different views depending on the screen size but as well different "view" channels, web, mobile, smart watch, AI etc...
• ordering, grouping and classification, sections, pages etc...

You can see some code here: https://github.com/THCLab/oca-interpres

[pknowl]

Allow me to introduce myself: I am @pknowl, the inventor of the Overlays Capture Architecture (OCA) concept and the founder of the overarching framework, Decentralised Semantics. I currently chair the Decentralised Semantics Working Group at The Human Colossus Foundation. My leadership primarily focuses on ensuring semantic interoperability and data harmonisation through utilising OCA, defending its core principles, while @mitfik focuses on the ecosystem of tools required to maintain the integrity of OCA as a decentralised semantic architecture.

Regarding @M-Wong 's query on attribute concatenation and the structural treatment of a citizen's name in semantic modelling, I'd like to provide a perspective that balances semantic precision and data protection. Rather than introducing a transformation overlay that aggregates attributes (such as firstname and lastname into fullname), the best practice is to treat "Name" as a referenced OCA bundle from the parent schema. This allows for a more detailed and accurate representation of the structural components of an individual's name while maintaining flexibility in how to present that information.

Here is an example of how a "Name" object can be structured as a referenced capture base:

{
  "type": "spec/capture_base/1.0",
  "classification": "NOGA:8411",
  "digest":"xxxxxx",
  "attributes": {
    "firstName": "Text",
    "middleName": "Text",
    "lastName": "Text",
    "fullName": "Text",
    "alias": "Text",
    "honorificPrefix": "Text",
    "honorificSuffix": "Text",
    "preferredName": "Text",
    "nickname": "Text",
    "maidenName": "Text"
  },
  "flagged_attributes": [
    "lastName",
    "fullName",
    "alias",
    "maidenName"
  ]
}

Why this approach matters:

By treating "Name" as a granular and well-defined standalone object, we gain significant advantages from a PII (Personally Identifiable Information) protection perspective. This allows us to:

1. Ensure granular PII flagging: Attributes such as lastName, fullName, alias, and maidenName are clearly flagged as PII due to their potential to uniquely identify an individual. Meanwhile, firstName may remain unflagged unless combined with other attributes (like lastName), ensuring accuracy in data classification.

2. Support for internationalisation and flexibility: You've correctly pointed out that different cultures handle names differently. By breaking the name down into distinct elements (e.g., firstName, lastName, alias), we allow for flexibility in how names are captured and displayed across different regions and contexts without enforcing a rigid, one-size-fits-all structure.

3. Early introduction of PII protections upstream: By defining and flagging these sensitive attributes at the structural level, we ensure that PII considerations are embedded early in the data lifecycle. This prevents potential exposure of sensitive information downstream, especially in contexts where data is shared across systems or jurisdictions.

4. Alignment with semantic interoperability: Defining the structure of "Name" in this manner supports broader semantic interoperability and data harmonisation efforts. This allows for seamless data exchange across different systems and jurisdictions, ensuring consistency while respecting local privacy regulations.

In summary, while a transformation overlay for concatenating attributes such as firstname and lastname may offer a temporary solution, the recommended approach within the OCA framework is to represent "Name" as a structured, granular schema of its own. This supports more accurate PII handling, maintains flexibility, and aligns with the long-term goal of semantic interoperability.

Please don't hesitate to reach out if you have further questions from a semantic modelling perspective or would like to explore this in more detail. I’ll keep an eye on the ongoing discussion and jump in if I feel I can contribute to any further discussion points.

[pknowl]

Similarly, you can apply the same semantic modeling approach for a referenced "Address" object. This structure ensures that sensitive attributes like street, postalCode, latitude, and fullAddress, etc. are flagged as PII for enhanced data protection, just as we've done with the "Name" object. By breaking down the address components, we enable precise PII flagging and ensure proper handling of sensitive information, offering flexibility for different use cases.

{
  "type": "spec/capture_base/1.0",
  "classification": "NOGA:8411",
  "digest":"yyyyyy",
  "attributes": {
    "street": "Text",
    "city": "Text",
    "state": "Text",
    "postalCode": "Text",
    "country": "Text",
    "apartmentNumber": "Text",
    "district": "Text",
    "region": "Text",
    "latitude": "Numeric",
    "longitude": "Numeric",
    "fullAddress": "Text"
  },
  "flagged_attributes": [
    "street",
    "apartmentNumber",
    "postalCode",
    "latitude",
    "longitude",
    "fullAddress"
  ]
} 

[pknowl]

For more information on establishing relationships between OCA Bundles, OCAFile supports references.
http://oca.colossi.network/ecosystem/ocafile.html#references

[M-Wong]

@pknowl Thanks for the insight. Splitting related attributes into a separate capture base and referencing it definitely makes sense from a data integrity and PII flagging point of view. However, I don't see how that solves the issue I raised in my original discussion and which you've further referenced in your bullet point Support for internationalisation....

Your examples both contain the data in an atomic format, which makes sense, as their presentation depends on where and how they are displayed. But there are also the attributes fullName and fullAddress, which I take as having the VC issuer include those fields in its data payload.

Let's assume I want to use the Aries branding overlay to display a VC as a card layout. The overlay defines a primary_attribute and secondary_attribute. Maybe I want to display firstName lastName as the primary_attribute and street streetNumber, postalCode city as the secondary_attribute (whether or not this makes sense from a UX standpoint is of course debatable).

Even the separate capture bases for name and address attributes are not flexible enough to achieve the above presentation, because the atomic fields cannot be aggregated via an overlay (meaning they'd have to be aggregated on the data layer in the VC payload) and the fields fullName and fullAddress are not flexible enough. Maybe in one locale I need to show lastName, firstName instead, which a transformation overlay with language property could achieve.
Please correct me if I misunderstood your examples.

[pknowl]

You raise an important point regarding the flexibility of presenting data, particularly when aggregating fields. From a semantic modeling perspective, any transformation and aggregation of attributes must consider PII flagging requirements. That was my main point. Developers working on Swiss eID and its verifiable credentials should have complete autonomy in building the presentation layer for their use case. We're here not to dictate or persuade developers to implement in a particular way but to remind them to always account for sensitivity flagging. Perhaps @mitfik can suggest a viable alternative to the presentation layer.  As indicated, OCA will scale through dominant design, with collaboration ensuring data integrity at all stages.

On a side note, your input is extremely valuable. If anyone wants to join the DSWG at HCF to discuss these points as a community, let me know, and I'll send out the invites. Your participation will be greatly appreciated.

[carlyh-micb]

Hello, I am Carly Huitema and I am leading the implementation of OCA into what we've called the Semantic Engine at Agri-food Data Canada (ADC). We like the overlay structure of OCA and the calculation of SAIDs for reproducibility, an important feature in research. We have a publication which also explains the approach.

We are also at the stage of creating new overlays to add to our schemas. However, our approach is a little different. We want to keep new overlays separate from the official specification, to preserve interoperability and keep things clear about what is created by us, and what is within the core OCA specification. Since SAIDs are calculated at the object level we want to avoid mixing OCA spec and our own overlays together in the same object where a SAID is calculated.

This draft specification is our design that we are currently implementing from. It is currently in my personal repository while being developed and if others are interested in developing it with us at ADC it could become a community effort. Right now we have objects: oca_bundle (core spec OCA), extensions (our overlays we add) and presentation (where we will stick presentation specific overlays). We can add other objects. We have code and can generate our own overlays and calculate SAIDs and generate the package.

The OCA Package is an attempt to add to OCA the functionalities we need while maintaining SAID values and providing guidance to harmonize syntax.

[carlyh-micb]

The draft specification of OCA Package is now: https://github.com/agrifooddatacanada/OCA_package_standard