Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Send an email to decentralized-semantics-wg@lists.trustoverip.org to request a calendar invite (you can subscribe to the mailing list at lists.trustoverip.org).

Agenda

Guiding Goal: Developing semantic components for further enhance OCA capabilities.

  • Welcome (Paul—5 mins)
  • Newcomer Introductions (WG, 5 mins)
  • Task Force Updates (WG, 10 mins)

  • Demo: An OCA Swagger implementation – [OpenAPI] (Presented by Robert—15 mins)

  • Topic: Transitive Trust, an alternative VC application (Paul—10 mins)

    • Although ZKP is certainly a functionality aspect that VCs should support for human-to-human masked interactions to enable authorisation for a holder to perform an activity or to gain authorised access to do something, They are not the best transport solution for any data payload of significant size between two governing entities: (i.) there is a limitation of 128 attributes (I believe) that a single VC can support so, if you wanted to send a large questionnaire containing 650 attributes, for example, you would have to build 5 VCs to transport the data. That is simply not a scalable or reasonable proposition for that particular transaction. (ii.) If you wanted to transport large image files (e.g medical images, high-res moving images, videos, etc.), again, VCs are not a viable option due to the lightweight nature of their design. They were created specifically for digital credentialing and certificates.

      However, what VCs are very good at is acting as a linking object to bundle a number of related data objects together as part of the same transaction. In this case, a VC could be used as a transport of trust (i.e. transitive trust) rather than a transport of data. An example of this type of use case might be if you wanted to port a large questionnaire, a supporting attachment, a linked consent credential and a privacy agreement all as one bundled package to another vendor. You could use a VC to tie all of those objects together where each VC attribute contains a decentralised resource identifier (DRI) (e.g. a hashlink) that links to a separate data object. By signing the VC, the bundle can be authorised. If any of the linked data objects are then altered, their corresponding DRI becomes invalid and, as a matter of course, the VC is invalidated. In this type of use case, the bundled objects can be stored and/or ported using an authorised-access transient data storage solution, e.g a semantic container. A VC would not be the best portability option for the data payload(s) in this case but its role as a mechanism for transitive trust is fundamental to the transaction process.

      VCs need to support and play a part in all of the above use cases. Although important, I envisage that ZKP will only ever be used for 5-10 percent of all use cases involving VCs. It is important to keep a broad perspective on how VCs can and should be used as the technology matures and different use cases come to the fore.

  • Topic: Creating an Entry Lists Library to house standard and non-standard lists of predefined entries (Paul—5 mins)

    • Standards are basically created by contributors from all around the world for the benefit of society. Rather than national standards organisations charging developers high fees for the implementation of a standard developed by a community or WG, open source developers often create their own library implementations to avoid these walled-garden approaches. e.g., https://iso3166.thephpleague.com 

      On that basis, it would appear to make sense for HCF to house an open source Entry Lists Library (ELL) which anyone can contribute to. People working on any OCA implementation would then be able to utilise standard or non-standard entry lists published by other contributors for their own applications. As OCA's popularity increases, the ELL would continue to evolve as more and more contributors contribute to the library. We could add a standalone feature in the OCA Editor to allow contributors to build lists on the fly which are then stored in the ELL for others to reuse. Within a relatively short amount of time, contributors will inevitably start uploading ISO standards, CDISC standards, IEEE standards, etc. into the library in line with OCA's increasing popularity.

  • OCA Specification document: A preview of the first RFC (Paul—5 mins)

  • Logistics (Paul—5 mins)

    1. Chairs
    2. Meeting schedule

      1. FHIR-OCA Object Transformation FG Kick-off meeting

Meeting Notes

Recording: 

https://zoom.us/rec/share/3dA2D7HhrGFLXKfnzGuAQvYjAtrKX6a80SVI_fZZz02qRM4JcuZtqTGlNcUPyECv


Participants (Name / Location / Time zone / Affiliation):


Leadership positions:

(Note: We plan to instigate an official submissions, nominations and voting process. In the meantime, please put your name down if you are interested in volunteering for either a Chair or Vice-chair position.)

  • Decentralized Semantics WG
    • Chair volunteers 
    • Vice-chair volunteers 
  • Imaging TF
    • Chair volunteers
    • Vice-chair volunteers
  • FHIR-OCA Object Transformation FG
    • Chair volunteers
    • Vice-chair volunteers
  • Notice & Consent TF
    • Chair volunteers
    • Vice-chair volunteers


  • No labels