Eclipse Decentralized Claims Protocol

The EMO is using this issue to track the progress of project creation. Help regarding the process can be found in the Eclipse Foundation Project Handbook.

The following image shows the workflow for Starting a Project at the Eclipse Foundation.

We are using scoped labels to identify where a project proposal is at any time during the onboarding process. These labels are mapped to the stages shown in the previous image and will define the "state" of this ticket. If you have doubts, just ask.

We'll use the due date of this issue to provide an estimation of the next date the EMO team will checkin with the project team. Sometimes, e.g. during the project creation time, the due date will coincide with the Project Creation date.

Project

Project proposal: Eclipse Decentralized Claims Protocol

Top level project: Technology

Basic Information

• License: Apache License, Version 2.0
• Patent License: Implementation Patent License

Pre-creation Checklist

To be completed by the EMO

• Project scope is well-defined
• Top-level Project selected
• PMC accepts the project (PMC has replied with +1)
• License(s) approved
• Project name -nor similar names- has NOT been previously used by the team
• Project name trademark approved. Trademark transfer agreement available here in case you need it.
• Project lead(s) identified
• Committers identified
• Committers have Eclipse Foundation Accounts
• Two weeks of community review completed

Being this a specification project, a Spec Committee ballot to aprove the project creation must run for at least one week

• Specification Committee ballot initiated
• Specification Committee ballot concluded successfully

Project resources to be created

Project Lead involvement needed Open source projects at the Eclipse Foundation are required to make use of certain Eclipse Foundation services. See the Handbook for more information on this subject.

• The project lead has confirmed the project shortname: dataspace-dcp

• The project lead has requested a project website repository in the comments

• The project lead has confirmed the following project resources are correct in the comment's section

• Project organization: https://github.com/eclipse-dataspace-dcp

• The project Lead has requested to enable the OtterDog tool to manage their GitHub project.

• Project mailing list: https://accounts.eclipse.org/mailing-list/dataspace-dcp-dev

Post-creation Checklist

To be completed by the EMO

EMO internal tasks:

• Project DB entry created
• Project lead(s) designated (DB)

Milestones:

• Project created
• Project provisioned (including at least one committer)
• Committer orientation completed (upon request)

After creation

Once the project is created the provisioning process starts with an email message being sent to each of the committers listed on the project proposal with instructions on how to engage in the committer paperwork process.

Committers should check their emails and complete the paperwork at their earliest convenience. No project resources are created until at least one committer is fully provisioned.

To be completed by the EMO

• GitLab ticket state set to Provisioning

After provisioning

Following provisioning, the project will be ready for initial contribution review. An initial contribution is basically the first set of project code contributions to the new Eclipse project. An initial contribution typically takes the form of an entire existing source code repository or some snapshot of an existing code base.

At this point, the project team might proceed to push their code into the requested repositories or coordinate with Webmaster and EMO to transfer existing ones. Once you've completed this process please notify EMO using this ticket.

To be completed by the EMO

• GitLab ticket state set to Initial Contribution

IP-check

To be completed by the EMO

Once the project has provided their initial contribution:

• IP check completed
• GitLab ticket state set to Fully Operational

changed due date to April 10, 2024

added EDPCommunityReview License Approval Request Project Proposal Spec ballotrequired Trademark Approval Request labels

assigned to @mdelgado624

@mmilinkovich we need your approval to use the Apache 2.0 license for the Eclipse Dataspace Identity and Trust Protocol.

@shmacdonald please initiate trademark search for Eclipse Dataspace Identity and Trust Protocol.

Use of APACHE-2.0 is approved.

The project lead has confirmed the project shortname: ds-idandtrust

That name is fine

The project lead has requested a project website repository in the comments I would like to request a website repository

The project lead has confirmed the following project resources are correct in the comment's section

Project organization: https://github.com/eclipse-ds-idandtrust

Correct

The project Lead has requested to enable the OtterDog tool to manage their GitHub project.

I'm not sure how to do that, can someone provide a pointer?

Re. Otterdog, it is a tool to manage GitHub organizations at scale using a configuration as code approach. It is actively developed by the Eclipse Foundation and used to manage its numerous projects hosted on GitHub. To know more: https://github.com/eclipse-csi/otterdog

Re. the naming, I'm currently in conversations with @javiervalino to define a convention that might suit the Dataspace projects, so the shortname might still change (slightly)

OK regarding the name. For OtterDog, do I need to enable something because it is unclear?

@jmarinoswf no need to enable anything. Just express your preference and we will enable the service when the project is created.

@jmarinoswf please also notice I've modified the project shortname to dspace-idtrust. Let me know if that works for you.

Yes, for me it's fine

For the EDC project we had the discussion that dspace (as pronounced "despace") is misleading for a project that aims on connecting things together. We therefore switched to eclipse-edc and might come up with a better shortname than dspace-idtrust (ds-idtrust, dataspace-idtrust-, eclipse-idtrust,...). BTW, same for #695 (closed)...

To help the community and reduce the likelihood of misunderstandings, wouldn't that be preferable to avoid abbreviation, acronyms and agree on a naming convention for all the proposals under the EDWG ?

• dspace-protocol
• dspace-identity-and-trust
• dspace-trust

removed License Approval Request label

marked the checklist item License(s) approved as completed

@mdelgado624 Is this now under community review?

@jmarinoswf it is! see the image included above so you can have a quick overview of the project creation process. Let me know if you have any questions!

ok thx!

changed the description

Hello,

When reading the IATP specification proposal, I noticed that the 3 described protocols flows BIP, CIP and VPP seem equivalent to the respective Self-Issued OpenID Provider v2, OpenID for Verifiable Credential Issuance and OpenID for Verifiable Presentations specifications.

Could you explain the reasons for this choice, which seems to lead to more fragmentation and a lower level of interoperability between wallets?

Best regards, Pierre

Hi,

We looked extensively at the OpenID specifications. Specifically, BIP uses the same formats defined by SIOP v2 and references the latter. For presentation and issuance, we concluded that they do not fit well with Dataspace Protocol (DSP) requirements:

1. Identity and trust are established between dataspace participants (organizations), while the OpenId specifications, in their current form, involve human interactions. Humans should not be in the loop for DSP interactions.
2. The protocol flows defined by the OpenID specifications are optimized for end-user devices, not service-to-service communications. Many of the OpenID flows are geared toward browsers and/or multiple device interactions, which does not match with DSP exchanges.
3. DSP interactions are asynchronous and we have a requirement for completely asynchronous issuance. Open ID has the concept of deferred endpoints, but this is not truly an asynchronous interaction.
4. Renewal flows are not well-specified in Open ID. The approach in IATP allows for automated credential renewal similar to ACME for certificates.
5. Fitting Open ID flows into the DSP protocol would significantly increase its complexity by adding numerous service-to-service requests and requiring adopters to expose authorization servers to external (outside an organization) clients.

I disagree that this will lead to fragmentation since the specifications are intended to establish a baseline for interoperability. A TCK will also be produced to promote interoperable implementations. In fact, our experience implementing IATP using existing enterprise wallets has been straightforward. There is one commercial wallet implementation and two open source implementations that were able to create IATP-compatible interfaces in a relatively short period of time (a month or two). Note the emphasis on enterprise - our use cases involve organizational credentials, not end-user wallets.

I hope this answers your questions.

Hi @jmarinoswf,

Thanks for your comments about the usage of the OpenID specification, if I may share mine through this reply.

Machine-to-Machine Interactions

1. Identity and trust are established between dataspace participants (organizations), while the OpenId specifications, in their current form, involve human interactions. Humans should not be in the loop for DSP interactions.
2. The protocol flows defined by the OpenID specifications are optimized for end-user devices, not service-to-service

About the human interaction only aspect of OpenID Connect for Verifiable Credentials. OIDC4VC is an extension of the OAuth 2.0 protocol which is originally built to manage secure exchanges in a machine-to-machine environment. As mentioned in the Roles chapter of the OAuth 2.0 specification:

client
     An application making protected resource requests on behalf of the
     resource owner and with its authorization.  The term "client" does
     not imply any particular implementation characteristics (e.g.,
     whether the application executes on a server, a desktop, or other
     devices).

I imagine you are referring to OIDC4VCI's specification flows when mentioning that they involve human interaction such as having to scan QRCodes. If that's the case, those flows are only illustrations of some of the possible flows as mentioned in the Core Concepts' chapter's last sentence.

Asynchronous Issuance

3. DSP interactions are asynchronous and we have a requirement for completely asynchronous issuance. Open ID has the concept of deferred endpoints, but this is not truly an asynchronous interaction.

I looked for more information about DSP's asynchronous issuance strategy but all I found is a callback address in the contract negotiation process, do you have more details about the asynchronous process you are referring to ?

OIDC4VCI is capable of asynchronous issuance through the deferred credential endpoint, wether you use a callback address called by the issuer or a polling mechanism on the wallet's side, it remains an asynchronous process as the resource isn't returned promptly.

Another advantage with OIDC4VCI is the possibility of issuing batches of verifiable credentials, them being immediately available or available in the near future through deferred issuance.

Renewal Flow

4. Renewal flows are not well-specified in Open ID. The approach in IATP allows for automated credential renewal similar to ACME for certificates.

The renewal flow is clearly defined in the OIDC4VCI specification as it refers to the refresh token mechanism in the OAuth 2.0 specification. The renewal process will be the responsibility of the wallet or the holder depending on the strategy, most cases should be managed by the wallet through a simple expiry date check.

Market Adoption

5. Fitting Open ID flows into the DSP protocol would significantly increase its complexity by adding numerous service-to-service requests and requiring adopters to expose authorization servers to external (outside an organization) clients.

I understand it will ask some work from the adopters but everything is based on OAuth 2.0 which is widely used and battle tested so libraries are available for that. Furthermore, if the adoption of OIDC4VC is as strong as the interest of the community for it, many new libraries managing OIDC4VC flows out-of-the-box will become available.

Moreover, a simple issuer service can be sufficient for most verifiable credential issuance requirements. Full blown authorization servers are always necessary with OIDC4VC.

Hoping this will help understand the value OpenID Connect for Verifiable Credentials brings to the market and the will of adoption the community has for it

Hi Vincent,

Thanks for your comments.

I imagine you are referring to OIDC4VCI's specification flows when mentioning that they involve human interaction such as having to scan QRCodes. If that's the case, those flows are only illustrations of some of the possible flows as mentioned in the Core Concepts' chapter's last sentence.

Yes we are aware of that, but those flows are not defined and the flows in the current specifications involve human interactions.

I looked for more information about DSP's asynchronous issuance strategy but all I found is a callback address in the contract negotiation process, do you have more details about the asynchronous process you are referring to ?

Here is a link to the specifications:

https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol

OIDC4VCI is capable of asynchronous issuance through the deferred credential endpoint, wether you use a callback address called by the issuer or a polling mechanism on the wallet's side, it remains an asynchronous process as the resource isn't returned promptly.

As I mentioned in my original comment, polling is not a true asynchronous mechanism. It's a synchronous way to wait for a response.

The renewal flow is clearly defined in the OIDC4VCI specification as it refers to the refresh token mechanism in the OAuth 2.0 specification. The renewal process will be the responsibility of the wallet or the holder depending on the strategy, most cases should be managed by the wallet through a simple expiry date check.

Yes, we are aware of the section but there are some important things left out. For example, as stated in the specification:

"How the Credential Issuer sends such a signal is out of scope of this specification."

I understand it will ask some work from the adopters but everything is based on OAuth 2.0 which is widely used and battle tested so libraries are available for that. Furthermore, if the adoption of OIDC4VC is as strong as the interest of the community for it, many new libraries managing OIDC4VC flows out-of-the-box will become available.

As you stated, the system-to-system flows still need to be defined for decentralized identities. There aren't any battle-tested libraries or software that implement such flows. Also, in our implementation experience, existing libraries can be easily used to support IATP. For example, there is one open-source implementation that uses common libraries such as Nimbus (in the case of JWT-based credentials). There is also an existing commercial wallet that was able to reuse all of its existing security infrastructure by creating a simple IATP facade.

Moreover, a simple issuer service can be sufficient for most verifiable credential issuance requirements.

Not for our use cases, for example, in the Catena-X dataspace.

I hope this answers your questions.

@mdelgado624 I think the two weeks of public review are over, correct? What are the next steps and how could I support? Some tasks at the top might already be done, at least I saw comments regarding the short name, license etc.

@mspiekermann we are waiting on the Specification Committee decision regarding the default Patent License of the Dataspaces WG. Once we have that we can move forward in the project creation process.

Hi,

Is it possible to confirm if this proposal is in sync or is expected to converge with the work done by the Open Wallet Foundation ?

For info, they are building a community driven overview of different wallets and agents, per type, feature and implemented protocols: https://openwallet-foundation.github.io/digital-wallet-and-agent-overviews-sig/

Best regards, Pierre

Hi @pgronlier

I'm unsure what being in "sync" or "convergence" entails. As far as I can tell, OWF primarily focuses on implementations as opposed to specifications.

The link points to a table of technologies and specifications, some of which IATP relies on.

@mdelgado624 Please change the project name to Eclipse Decentralized Claims Protocol

changed title from Eclipse Dataspace Identity and Trust Protocol to Eclipse Decentralized Claims Protocol

changed the description

marked the checklist item Project name trademark approved. Trademark transfer agreement available here in case you need it. as completed

marked the checklist item Project name -nor similar names- has NOT been previously used by the team as completed

marked the checklist item Top-level Project selected as completed

removed Trademark Approval Request label

marked the checklist item PMC accepts the project (PMC has replied with +1) as completed

marked the checklist item Committers have Eclipse Foundation Accounts as completed

marked the checklist item Two weeks of community review completed as completed

marked the checklist item Committers have Eclipse Foundation Accounts as incomplete

marked the checklist item Committers have Eclipse Foundation Accounts as completed

changed the description

marked the checklist item Specification Committee ballot initiated as completed

changed due date to May 28, 2024

added Spec ballotinitiated label and removed Spec ballotrequired label

The proposal for DCP returns HTTP 403 [1]. Is there already a public page for the project phase?

[1] https://projects.eclipse.org/proposals/eclipse-dataspace-decentralized-claims-protocol

@arnoweiss tt works fine for me. If the problem persist, please open an issue in our HelpDesk.

added Spec ballotsuccessful label and removed Spec ballotinitiated label

marked the checklist item Specification Committee ballot concluded successfully as completed

marked the checklist item The project lead has confirmed the following project resources are correct in the comment's section as completed

marked the checklist item The project Lead has requested to enable the OtterDog tool to manage their GitHub project. as completed

marked the checklist item The project lead has confirmed the project shortname: dataspace-dcp as completed

This creation review has concluded successfully and the Eclipse Decentralized Claims Protocol has now been created. Committers listed in the proposal should receive their paperwork soon, please make sure to complete it at your earliest convenience. Notice project resources are not created until at least one committer has completed their paperwork.

@webmaster please start the provisioning process.

added EDPProvisioning label and removed EDPCommunityReview label

assigned to @webmaster

The project provisioning process is complete! Here you will find all of the information regarding resources allocated to your project:

Source Code Management:

A new organisation has been created at Github for your project: https://github.com/eclipse-dataspace-dcp .  Committers that have added their Github ID to their Eclipse.org accounts will start receiving invites to join the Dataspace-DCP Github team shortly.

Issue Tracker: 

Github issues have been enabled for your project.

Outbound Communication:

Mailing list: https://accounts.eclipse.org/mailing-list/dataspace-dcp-dev

Downloads: http://download.eclipse.org/dataspace-dcp

Archives: http://archive.eclipse.org/dataspace-dcp

Builds: You can upload releases to Dataspace-DCP via SFTP or SCP from a CI instance at Eclipse.org

Older builds should be moved to the archives area when they are no longer required.You can do this by visiting http://download.eclipse.org/dataspace-dcp in your favourite web browser and using the web ui.

I think all that remains is to enable Otterdog. @heurtemattes , @netomi would you be so kind as to sort that out?

Otterdog has been enabled for the eclipse-dataspace-dcp organization.

added EDPInitial Contribution label and removed EDPProvisioning label

@jmarinoswf the provisioning process is now completed! You can check in your code into new GitHub organisation that was created for your project: https://github.com/eclipse-dataspace-dcp

If you need any assistance with the move (existing repositories or creation of a particular strusture), please engage with @webmaster (either here or opening a dedicated issue on our GitLab HelpDesk)

@webmaster please assist @jmarinoswf with the initial contribution. He would like to push the history from the original repository to the new one.

Well the fastest solution if the original repo is also on Github is to simply invite 'eclipsewebmaster' as an admin on it, and then we can simply move it into place within github.com/eclipse-dataspace-dcp .

Otherwise we'll need to coordinate a time to suspend the validation plugin on Dataspace DCP so the content can be pushed.

added Successful label

@mward Thanks, I added it to the repo.

@webmaster can you please assist with the repo move?

@mdelgado624 @mward Can we move the repo over? We are waiting to start work in the specification project and this is blocking us? Thx.

mentioned in issue eclipsefdn/helpdesk#4900 (closed)

@mdelgado624 Can someone please help us with this since it is blocking our progress? We have not been able to make any progress for several weeks now. Otherwise, I will force push the existing repository to the specification repository, and we will continue in that mode.

I'm on it. We are in the holiday season, so this request fell between the cracks.

Repo has been moved to https://github.com/eclipse-dataspace-dcp/decentralized-claims-protocol.

Thanks!

@jmarinoswf can we consider the contents in the EF repository as the INitial Contribution of the project? Please let me know so we can start the automatic IP review.

Yes thank you

So as the IP-Ticket [1] is closed, I assume that there's no IP-related blocker for further contributions to the DCP.

[1] iplab#15967 (closed)

added IP review label

changed due date to August 21, 2024

marked this issue as related to iplab#15967 (closed)

marked the checklist item Project DB entry created as completed

marked the checklist item Project lead(s) designated (DB) as completed

marked the checklist item Project created as completed

marked the checklist item Project provisioned (including at least one committer) as completed

marked the checklist item GitLab ticket state set to Provisioning as completed

marked the checklist item GitLab ticket state set to Initial Contribution as completed

changed due date to September 04, 2024

The project's initial contribution has been approved. You can continue to work normally and we can declare the project as fully operational. Please make sure to properly manage your IP at all times. We strongly recommend you integrate the use of the Eclipse Dash License Tool into your project builds, it will help you vet all your 3rd party dependencies.

Please reach out to EMO when you're ready to schedule your first project review.

Thak you!

closed

removed IP review label

added EDPOperational label and removed EDPInitial Contribution label