Report Technical session #1 – April 1st 2022

• Laurens Debackere – Digital Flanders
• Pieter Heyvaert – Ghent University, IDLab – imec

Agenda

1. Introduction
2. Where to find/gather documentation?
3. Authentication and authorization
   1. Different methods
   2. Verifiable credentials, decentralized identifiers, and linked data integrity
   3. Real-world use cases
   4. How to set up an identity provider and how to stay up to date with respect to changes to the specs?
4. How to make sure qualitative data is stored in pods when looking at interoperability and discoverability?
5. Closing and actions

Introduction

Pieter introduces the community to the concept of SolidLab Challenges and the recently introduced Github repository.

SolidLab Challenges

Participants are encouraged to provide their challenges and potential use cases to SolidLab via a Github repository:

• List of challenges at https://github.com/SolidLabResearch/Challenges/ 
• Example at https://github.com/SolidLabResearch/Challenges/issues/4 

Where to gather/find documentation?

We detail some pointers to useful documentation resources on Solid and the broader Linked Data ecosystem. The community is also asked to share their own resources, this resulted in the following overview, which could be the basis of an additional page on the Solid community website dedicated to gathering documentation:

Specification & General Documentation

• Solid Project Technical Reference (https://solidproject.org/TR/)
• Solid Project Website (https://solidproject.org/)

Community

• Solid Community (Flanders) (https://solidcommunity.be/)
• Solid Community Gitter (https://gitter.im/solid/home)
• Solid Forums (https://forum.solidproject.org/)

Tools, Libraries & Servers

• Server
  • https://github.com/CommunitySolidServer/CommunitySolidServer 
• Libraries
  • JS/TS
    • https://github.com/inrupt/solid-client-authn-js 
    • https://comunica.dev/ 
  • Java
    • https://github.com/janeirodigital/sai-authentication-java
    • https://github.com/Konsolidate-eu/solid-auth 

Other

• SolidLab Challenges (https://github.com/SolidLabResearch/)
• Community Solid Server tutorial (https://github.com/KNowledgeOnWebScale/solid-linked-data-workshops-hands-on-exercises/blob/main/css-tutorial.md)

Authentication & Authorization

We discussed the specifics of authentication in Solid, and touched upon some of the challenges & use cases regarding authorization.

Different methods of authentication

Whereas Solid OIDC currently governs browser-based sign in to the Solid Pod, via an extension of the OpenID Connect 1.0 specification, the Solid Authentication Panel is looking for feedback on alternative authentication flows. These do not fit the common browser based sign in that is widely used in Solid. Feedback can be provided via Github, on the Solid OIDC repository (https://github.com/solid/solid-oidc/blob/main/alternative-flows.md).

The community members showed specific interest in machine to machine authentication scenarios, for example to enable automated data analysis, AI/ML applications, and so on.

Data Authentication

The subject of data authentication also stirred the interest of a number of participants. For this capability the Solid community mainly looks at the W3C’s Verifiable Credentials recommendation (https://www.w3.org/TR/vc-data-model/). The participants noted potential use cases for integration with distributed ledgers (blockchain), but also wondered how this would interact with existing PKI infrastructure.

Of particular note is how this attestation mechanism could play a role in the eIDAS/2 and Digital Wallet ecosystem that is being implemented at the EU-level. Alignment with its concepts of qualified signatures and qualified attestations is critical.

Use Cases shared with the community

Among the participants, many are interested in the Solid protocol and its applications in their domain. We saw attendance from identity providers, cloud providers, other government agencies, researchers, and so on. A couple of the participants already have more concrete proof of concepts in their pipeline. However the majority seems to still be in an exploratory phase

Solid-OIDC IdPs and Changes to the Specification

Next, we highlighted some of the available Solid-OIDC IdPs that community members can use for development or exploration of the Solid protocol. (e.g. https://pod.inrupt.com/, Community Solid Server, https://solidcommunity.net/, …) Also, a number of changes to the Solid-OIDC specification were briefly discussed with the community, like the introduction of UMA 2.0 (User-Managed Access) in the Solid authentication flow for resource access, changes to the names of specific claims and the use of the identity token instead of the access token in requests.

The community expressed particular interest in having a recurring agenda point highlighting changes in the Solid specifications.

Data Interoperability & Data Quality

Finally, we rounded off this session with an agenda point on data interoperability and more specifically regarding ontology discovery, design and publication. Many community members noted that it is difficult to start developing and publishing their own ontologies. Also they highlighted specific cases they encountered, i.e. what should one do if standards exist but these are not semantic (e.g. FIHR standard for health data, ISO standard for barcodes, …).

Furthermore, community members expressed interest in how the Flemish OSLO initiative plans to play a role in ontology design for the Solid community. Will OSLO actively participate in standardization tracks with private parties, or take on a supportive role in providing tools and best practices, …

The community notes there is a particular interest in a session on the lessons learned in semantic modeling and ontology design by the OSLO team. Also pointers to documentation or other best practices would be desired.

Closing questions & remarks

• How do you see the collaboration between Solid and existing identity hubs that focus more on offering connectivity to the potential private users?
  • This is a very interesting topic to further explore, currently Digital Flanders isn’t depending on Solid as a full-fledged authentication mechanism in use cases, however the Solid-OIDC specification definitely leaves room for such a role for the IdP.
• VITO notes the five main challenges they identified in Solid

• Querying the whole POD
  • Some interest has been shown for query mechanisms in the Solid Pod recently, so this could make for an interesting SolidLab challenge.
• Containers en datasets: where is the data located? (graph based approach?)
  • Recently ShapeTrees has been proposed as having potential in resolving some of these challenges (https://shapetrees.org/TR/specification/).
• Fine-grained autorisations
  • This is a challenge identified by many, a couple of community members are trying to tackle this problem in the Data Interoperability Panel as well (https://github.com/solid/data-interoperability-panel).
• Ontologies: What if you need to add links that aren’t present in the ontologies that are used (e.g. FIHR)?
  • We will follow up on this in a future session on ontology design with the Technical Community.
• Machine to machine integration (analysers/profilers…) 
  • Definitely useful to add your use cases to the Solid OIDC repository (https://github.com/solid/solid-oidc/blob/main/alternative-flows.md)
• What about deployment infrastructure? Where can we find documentation about deployment infrastructure requirements for Solid, like physical location, datacenter requirements, kubernetes, …
  • Running a Solid server doesn’t differ in important ways from typical backend web applications, you can find inspiration in the CSS repository. (https://github.com/CommunitySolidServer/CommunitySolidServer). However, note that specific requirements may be introduced for some use cases (e.g. GDPR, SCHREMS II, …), we refer to the organizations in the lead for concrete use cases in order to learn which requirements they set forward for e.g. regulatory compliance.