Type
Creation
State
Ongoing
End Date of the Review Period
Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Links
- Log in to post comments
This is a joint comment from
Submitted by James Marino on Mon, 03/25/2024 - 14:12
This is a joint comment from Peter Koen, Jim Marino, Julia Pampus, and Markus Spiekermann:
After reading the "Eclipse Trust Protocol Proposal," we have several clarifying questions and comments about the scope of the proposed work.
Our first question is if the proposal is for a specification or an implementation? If it is an implementation, it is unclear what the governing specification is (is there a governing specification?) If it is a specification, will there be separate implementation projects proposed for Eclipse or another open-source venue?
It is not clear who "trust" is targeted at. The project title, "Eclipse Trust Protocol," is too vague and open-ended. Does "trust" involve dataspace participants, workloads like SPIFFE and SPIRE, end users, or organizations? The proposed work appears to be for "data exchange." If so, it should clearly state that and discuss what parties are targeted and how.
The proposal states:
"Eclipse Trust Protocol implements an end-to-end holistic approach to seamlessly integrate, anchor, and enforce negotiated data exchange agreements throughout the underlying infrastructure, encompassing processes related to data processing, storage, and transfer."
What does the above mean, and how does it relate to Eclipse Dataspace Protocol Specifications? Will this work be based on DSP, and in particular, its policy format, contract negotiation protocol, and transfer process protocol? We are not arguing that it should, but clarifying this is important because it will directly impact the project scope.
The scope states:
"In scope:
To specify the information model and workflow enabling policy reasoning based on gathered and compiled claims and evidences.
To specify the information model and workflow creating legally relevant proofs in line with the civil law of obligations.
To specify protocols and formats enabling and enforcing the above, including the enforcement of the agreement resulting from the negotiation and the capability to prove its proper execution."
Based on this scope, it appears the proposal is to define more than an information model covering trust "attributes." The term "workflow" is extremely broad and could be interpreted as including message exchange patterns for establishing identity, presenting data policies, presenting verifiable credentials, negotiating contracts, and establishing data transfer connections. If the scope is only some of those and not others, that should be explicitly spelled out and detailed.
The list of technical specifications is also extremely broad:
"In detail, the current implementation is based on W3C JSON-LD, W3C VC, W3C SHACL, W3C SPARQL, W3C DID, X509, ETSI TS 119 312 for the data format and OIDC4VCi, OIDC4VP, EBSI for the APIs."
What is the architectural picture tying these disparate technologies together?
Peter, Jim, Julia, and Markus
This proposal is listed on
Submitted by Sebastian Bader on Tue, 03/26/2024 - 09:01
This proposal is listed on https://projects.eclipse.org/working-group/eclipse-dataspace so it seems to have a relation to the other Eclipse dataspace activities. Reading through the text, however, I don't understand the difference to the other two (Eclipse Dataspace Identity and Trust Protocol & Eclipse Dataspace Protocol). Why is this one needed in addition? Why is it not possible to merge it with the others?
Re: This proposal is listed on
Submitted by James Marino on Wed, 03/27/2024 - 02:59
In reply to This proposal is listed on by Sebastian Bader
It's unclear to us what the relationship to the other dataspace projects is, hence the questions we raised to clarify that. I see the possibility that this project focuses on a profile of the Identity and Trust Protocol to define a specific trust model for particular use cases. The Identity and Trust Protocol scope is specifically limited to allow other projects to create profiles.
As written, the scope of this project proposal is much broader than specifying a trust model. It appears the project aims to define alternative protocols to the DSP specifications. I also think that is fine, but the scope should clearly state whether it will be built on DSP or be an alternative.
I would suggest you move this
Submitted by Maria Teresa Delgado on Thu, 03/28/2024 - 19:03
I would suggest you move this discussion to the GitLab ticket linked above: https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/714
PMI comments require moderation wich might cause some delays in the posting.