Response to DCP vs OID4VC

[wistefan]

Introduction

The recently published article on Eclipse Decentralized Claims Protocol & OpenID4VC Protocol states there are a number of issues with OID4VC which do not really exist. Some might stem from a misunderstanding of the protocol or the scope of the protocol being expanded beyond authentication by the authors. It seems that the comparison follows a very narrow definition of interactions inside a Data Space, where participants can only be directly represented by a Service Agent (the Data Space Connector). However, none of the usual definitions (for example by the Data Spaces Support Center) does enforce that. In practice, various use-cases requiring users and services to act more independently from the central participating organisation emerge, thus the flexibility and support for Human-to-Machine(H2M) or, in other words, Business-to-Customer(B2C) or Business-to-Employee(B2E) in OID4VC should rather be seen as an advantage for Data Spaces. Even the described example of Manufacturing-X could benefit from the separation of organizational identity and actor identity, to make the system less reliant on central components and instead allow actors (be them humans, software agents or devices) to act more independently from the organization, while still keeping the ability to identify it. In the following, we will describe the misconceptions behind the referred issues.

On "Issues this creates for OID4VC"

How is the automatic discovery of a DID going to happen? OpenID does not have a process for this that would not require a user to share this information actively. Any process devised to enable automatic discovery on top of OpenID could potentially lead to either DDOS attacks against the identity store or the leak of existence of data sharing contract offers that the other party isn’t authorized to know.

DID is a mechanism to prove decentralized identity. Service Discovery is not one of its core features, just an optional side-mechanism, supported by some of them. Relying on DID's for service discovery limits the freedom of choice for the Data Space and participants in choosing the ideal identity mechanism. It also increases the hurdle for a consumer to join a Data Space, since did-methods supporting service discovery require more effort than simpler solutions (like f.e. did:key). Tightly coupling the protocol to a specific Identifier-Schema (e.g. DID), also holds the risk of becoming incompatible with public regulation and standards in the future. The EUDI Wallet Reference Architecture for example stays identifier agnostic, similar can be expected from the upcoming EUDI Business Wallets. OID4VC is agnostic in that regard, which is an advantage for future compatibility.

There is no mechanism in OID4VC or OID4VP that would allow for the correlation of contract offers and agreements to determine policies.

Offers and Agreements belong to the Data Space Protocol, not to the identification layer. In a DSP-based data-exchange, the underlying agreement (and offer) can be resolved from the connected Transfer Process. Enforcement of those policies can be done in OID4VC based systems, too. The instance representing the end-user can reason about the credentials/claims to be presented, while enforcement of the policies should happen as part of the authorization flow, in direct connection with the requested data assets. The flow in OID4VC and the DCP are very similar here. In both cases, the verifier asks for the presentation of claims/credentials (in DCP Step 6 of the Presentation Flow, in OID4VP through the Authorization Request), then verifies the presented claims/credentials and leaves the policy evaluation open for following steps/flows.

The Authorization Request Reference with Consent Object would need to be forwarded from the Dataspace Connector to the Wallet, which adds a potential attack vector. This process would need to be standardized so different wallet implementations can be interoperable.

By using the Same-Device Flow, this risk can be mitigated. During M2M exchanges, the interaction with wallet and verifier usually will happen from the same device/environment, thus no forwarding between different entities is required. Depending on the implementation and use-case, it would even be possible to have the same component fulfilling the wallet and end-user roles, similar to the way services used to hold their own credentials in OIDC. If wallet and end-user are represented by different components, the consent-mechanism between both of them still does not touch the interfaces between the connectors, thus not necessarily has to be standardized in the context of Data Spaces. It would be up to the participant to choose a wallet with connectivity to its service. This is very similar to other already established secret-management systems (f.e. HashiCorp Vault), that also only needs to be compatible with the services directly using them.

Custom Wallet extensions are needed for the comparison of the consent object to the presentation definition.

See the previous paragraph. Beside that, the DCP also requires comparison of the access token issued by the STS with the request received in the Credential Service. How this is done is up to the implementation of the Credential Service, the same way it is for the acting services in OID4VP.

The Authentication Token needs to be bound to specific credentials and Proof of Possession is required, how is the end-user transferring this to the organization on which behalf the contract negotiation is being conducted?

This is a topic of credential hierarchies and the general trust framework, rather than a question of the protocol. The Authentication Token (in OID4VP, the Verifiable Presentation) might contain credentials delegating powers from the organisation to the end-user. This credential will be bound to the end-user and together with the use-case required credentials can prove the possession in the organisation.
An example of such hierarchy could be found in the Gaia-X Identity Credential Access Management. The end-user could use a "Service Party Credential" and "Access Entitlement Credential" issued by the organisation, containing the powers to use the requested credentials and present them together with the requested credentials. This approach holds the advantage of very fine-grained rights-management inside an organisation, while it keeps the benefits of services (and humans) acting independently from a central infrastructure.

How can the connector use the Demonstration of Proof of Possession for the authentication token without the private key of the wallet?

See previous paragraph. An organisation can have an unlimited number of Client-Entities acting in the data exchange on behalf of the organisation. They will hold their own identities and use their connected private keys to sign the tokens. In order to prove their entitlement, they will present additional credentials, provided by their organisation (for example using the hierarchies from Gaia-X Identity Credential Access Management).

The token needs to be correlated with the DSP offer messages to guard against clients using a token to obtain different datasets.

When using the DSP, every Transfer Process contains the ID of the underlying agreement. This ID can be used to resolve the policies relevant for the datasets and evaluate them on the token and data request.

How does the connector evaluate policies at this point because it needs the original credentials? E.g.: a policy constraint may require a value in the credential subject. Or a credential claim is required to fetch data.

The verifier is free to embed all required information into the token, so that its authorization layer is able to evaluate all constraints from the policies. Thus, the required subject or claim could just be put into the token. This is a flexibility that the provider has. If this is not enough, the provider could even store a reference to the presented (and verified credentials) and include this reference in the token. When getting the token presented, it then can (internally) resolve this reference and reason on the whole presentation.

Conclusion

The OID4VC set of protocols are best suited for the use of claims issuance, presentation and verification in Data Spaces which are not just restricted to cover Machine-to-Machine(M2M) or Business-to-Business (B2B) scenarios for the exchange of datasets, but also aim to enable natural persons, applications or devices linked to organisations be able to consume data services offered by data product providers, managing identity(and consequently authorization) at a grain-level finer than organizations. While they can be used in plain B2B/M2M scenarios where just identification of organizations may be required, a much broader set of Data Spaces use cases can be enabled by OID4VC involving users, linked or not linked to organizations.

[ssteinbuss]

Hi @wistefan ,

Thanks a lot for the elaboration on the matter. Your contribution is highly appreciated. It will be addressed in the next few days, so please give us some time to process it. Looking forward to the collaboration.

[ssteinbuss]

Thanks @wistefan well balanced article from #FIWARE DATA SPACES WORKING GROUP. #FIWARE Community is always in forefront countering the misinformation

Dear @ccsr, thanks for your comment. Nevertheless, I would like to point out that we have a Code of Conduct for collaboration in the IDSA projects. I am sure that you must have missed that. Please take a look. Looking forward to a constructive collaboration.

[mspiekermann]

One of the main issues is mixing up the concepts of dataspaces and data ecosystems. Dataspaces are one building block of data ecosystems but doesn't span the whole continuum from tech over business to legal. Dataspaces are the technical governance framework enabling all kind of business on top. Clear interfaces allow to extend dataspaces with trust frameworks, policy models, semantic vocabularies, and even business models (feel free to create a data marketplace), which forms the data ecosystem. B2C and B2E cases are great and they should and will become important applications within our increasingly digital world. But, those cases are still a different layer.

My IP is also not bound to my personal credentials, while I am the one that needs to login at Amazon Marketplace and (unfortunately) pay with my bank account data. Difference here as well is the layer, protocol and the correspondig responsibilities.

For M2M and B2B cases there is no official specification in OID and I don't see them in the near future. It is nice that there are workaround and ways to achieve this (e.g. business wallets). However, there still is the risk coming with non-standard use, which DCP solves through EF PAS path.

[mspiekermann]

This is btw not an issue and should be changed to a discussion. @ssteinbuss we should enable discussions in this repo, WDYT?!

[PeterKoen-MSFT]

Hi @wistefan,

I believe that there is some misunderstanding on a few critical design choices for IDSA Dataspace Architecture. Let me provide some additional detail which will clarify the article and probably strengthen your understanding of what an IDSA Dataspace is and it will provide some background information on the design decisions for the protocols.

First let's start with a detailed view on what we are talking about here: Unfortunately, today the term Dataspaces is being used for a lot of different things: Data Ecosystems, Applications, Business Processes, Governance Frameworks, etc.. The article references specifically what is under the purview of IDSA Architecture Working Group:
Dataspaces as a technical Design Pattern that enables trusted data sharing between organizations in a business & governance model neutral way.

In Dataspaces, as understood by IDSA (IDSA Manifesto & IDSA Rulebook) it's organizations that need to share data with each other in a fully automatable way. It does not include the human end-user layer.
After data is shared it is managed by organizational Data Management Systems. Users interact with Data Applications, which in turn interact with the Data Management Systems.
Actors in Dataspaces are Software Agents representing the organization participating in a Dataspace.

Should information about the human end-user be required at the level of the software agent (e.g. for compliance reasons to track who authorized the data sharing) it can be included as an attribute within the data sharing contract.

Now that the scope has been clarified, let's look at your comments in a bit more detail and let me explain why they show a misunderstanding of the scope of dataspaces and the protocols:

Misunderstanding 1

DID is a mechanism to prove decentralized identity. Service Discovery is not one of its core features, just an optional side-mechanism, supported by some of them. Relying on DID's for service discovery limits the freedom of choice for the Data Space and participants in choosing the ideal identity mechanism. It also increases the hurdle for a consumer to join a Data Space, since did-methods supporting service discovery require more effort than simpler solutions (like f.e. did:key). Tightly coupling the protocol to a specific Identifier-Schema (e.g. DID), also holds the risk of becoming incompatible with public regulation and standards in the future. The EUDI Wallet Reference Architecture for example stays identifier agnostic, similar can be expected from the upcoming EUDI Business Wallets. OID4VC is agnostic in that regard, which is an advantage for future compatibility.

DSP does not "rely" on DID's for service discovery. More correctly, it says if DID documents are used for catalog service discovery, there is a specific format for doing so. This is clearly explained in the DSP specification here. Other mechanisms could also be used.

DCP is based on DIDs. The only reason DCP mandates Web DIDs is for interoperability. There has to be at least one common DID method if interoperability is required. Additional DID methods can easily be supported in the future, if requirements present themselves.

There is currently no specification for "EUDI Business Wallets," so this is just speculation and therefore not something that can be included in design considerations for current protocol work.

Misunderstanding 2

There is no mechanism in OID4VC or OID4VP that would allow for the correlation of contract offers and agreements to determine policies.

Offers and Agreements belong to the Data Space Protocol, not to the identification layer. In a DSP-based data-exchange, the underlying agreement (and offer) can be resolved from the connected Transfer Process. Enforcement of those policies can be done in OID4VC based systems, too. The instance representing the end-user can reason about the credentials/claims to be presented, while enforcement of the policies should happen as part of the authorization flow, in direct connection with the requested data assets. The flow in OID4VC and the DCP are very similar here. In both cases, the verifier asks for the presentation of claims/credentials (in DCP Step 6 of the Presentation Flow, in OID4VP through the Authorization Request), then verifies the presented claims/credentials and leaves the policy evaluation open for following steps/flows.

Nowhere does the article assert that Offers and Agreements belong to the "identification layer".

The statement, "In a DSP-based data-exchange, the underlying agreement (and offer) can be resolved from the connected Transfer Process" makes no sense in the context of DSP. The "underlying agreement" and "offer" are not resolved from the "connected Transfer Process." A transfer process is essentially a control channel for data transfer.

DCP and OpenID4VC are very different in how VCs are presented to the provider.

Misunderstanding 3

By using the Same-Device Flow, this risk can be mitigated. During M2M exchanges, the interaction with wallet and verifier usually will happen from the same device/environment, thus no forwarding between different entities is required. Depending on the implementation and use-case, it would even be possible to have the same component fulfilling the wallet and end-user roles, similar to the way services used to hold their own credentials in OIDC. If wallet and end-user are represented by different components, the consent-mechanism between both of them still does not touch the interfaces between the connectors, thus not necessarily has to be standardized in the context of Data Spaces. It would be up to the participant to choose a wallet with connectivity to its service. This is very similar to other already established secret-management systems (f.e. HashiCorp Vault), that also only needs to be compatible with the services directly using them.

This gets at the heart of the misunderstanding. In order to be OpenID4VC compliant, an implementation MUST follow one of the defined flows. There are two of them: The Same Device Flow and the Cross Device Flow. The Same Device flow is not feasible in the context of M2M interactions. As defined in the OpenID4VC spec here

Figure 1 is a diagram of a flow where the End-User presents a Credential to a Verifier interacting with the End-User on the same device that the device the Wallet resides on.

The flow utilizes simple redirects to pass Authorization Request and Response between the Verifier and the Wallet. The Presentations are returned to the Verifier in the fragment part of the redirect URI, when Response Mode is fragment.

The security assumption here is that the interactions are happening on a single device in the control of an End User (human). Which just doesn't makes sense in the context of an enterprise deployment of a software agent. Typically, the connector and credential service (wallet) instances will be clustered and deployed independently.

That leaves the Cross Device Flow. And that flow must adhere to the diagram referenced in Figure 5 of the specification if it is to follow OpenID4VC. Otherwise, one would have to invent an entirely different protocol that would allow VCs to be presented to the provider's verifier. This protocol would face several issues once it's being used in real world enterprise scenarios:, e.g. it would have to use an endpoint to post credentials which would reply with the JWT. The JWT would then need to be forwarded along the DSP request to the provider connector. I have my doubts that this would work as it would need to provide the JWT token in the DSP request HTTP header. As many HTTP Load Balancers limit the header size for security reasons this would create a limit of 8k, which is generally to small for many use cases.

I therefore doubt that such a custom protocol (at this point it's really hard to speak about the OID standard, as it no longer includes their base condition of a human controlled wallet and it is a custom sequence flow) would work in practice.

However, if you feel strongly about this being the right path, then there is nothing that prohibits you from creating such a protocol and implementing it. The way the protocol stack is designed is straight forward: DSP is the foundational protocol that guarantees interoperability in the discovery, negotiation and transfer orchestration of Data Sharing Contracts. DCP is "just" one possible (and very thoughtfully designed) protocol for the claims management in dataspaces. As long as you support DSP there is no reason why you can't implement a different protocol for managing claims.
This has always been part of the IDSA design: every dataspace can decide if they want a fully decentralized solution, or include federated, or centralized elements (e.g. identity management, catalogs, etc...).

After all the world of open-source is one of discussion, contributions and meritocracy. If you disagree with one approach, you develop a new one that you deem to be better. I absolutely encourage everyone to pursue their own conviction, experiments, designs and implementations. I'm happy to adjust my viewpoint if my views are proven wrong. However, so far I couldn't find arguments that would compel me to abandon the ideas and principles of DCP.

[PeterKoen-MSFT]

Thanks @wistefan well balanced article from #FIWARE DATA SPACES WORKING GROUP. #FIWARE Community is always in forefront countering the misinformation

Dear @ccsr,
I have gotten to know you as a thoughtful individual. It saddens me to see that you are defaming a technical discussion and extemporization on technical facts as misinformation.
I would very much appreciate it if we could keep it civilized in the technological discussion and not resort to polemic blame of differing views.
Thank you,
Peter

[jimmarino]

EDC committer, DSP committer, and DCP Editor here to further elaborate on what @PeterKoen-MSFT has said:

• DSP is an Eclipse Specification governed by the rules of the Eclipse Foundation and not subject to external bodies such as the Data Spaces Support Center. This misunderstanding has surfaced in the past and should be clarified.
• DCP is the interoperable protocol for decentralized identity and claims as mandated by the Eclipse Dataspace Working Group (EDWG). Protocols for other (non-decentralized) schemes may appear in the future, but DCP is required for interoperability in decentralized schemes. This means, among other things, all profile specifications under the EDWG umbrella must be compatible with DSP and DCP.
• People are free to use or invent whatever identity and claims protocol they want, but it will not be interoperable with the protocol stack specified by EDWG.
• If someone believes it is possible to create a decentralized identity and claims protocol that works with all target DSP use cases using only what is specified in the OpenID4VC standard, I would be interested in seeing the code. Specifically, the code must implement the Cross Device Flow referenced in the article, not deviate from it or introduce custom extensions, and support all DSP state machine interactions. There are frequent claims that this code exists, or is possible, but it has yet to be produced.
• Note that the last point is different than stating "it is not possible to perform M2M interactions using OpenID4VC." The OpenID4VC specification will not work without defining custom behavior to automate consent interactions. This is explained at length in the article and the DCP specification.
• Using the Same Device Flow makes no sense in the context of an enterprise deployment for obvious reasons that should not need further elaboration.

Many technical misunderstandings could have been avoided if the DSP and DCP projects had been engaged directly and questions had been asked, instead of making assumptions. In the spirit of constructive engagement, please share the code that integrates DSP and the OpenID4VC Cross Device Flow so we can have a tangible discussion.

[wistefan]

I think one of the fundamental differences in our view of interactions in a data space is, that in you case the service agents always directly represent the organization, while in our case the service agents act on-behalf of the organizations, using their own identity and the powers they got delegated by the organization, very similar to the way interactions between organizations happen in the physical word. Doing so enables a much broader set of interactions in data spaces. It also is the essential prerequisite to build a system using OID4VC as we propose.

DSP does not "rely" on DID's for service discovery. More correctly, it says if DID documents are used for catalog service discovery, there is a specific format for doing so. This is clearly explained in the DSP specification here. Other mechanisms could also be used.
DCP is based on DIDs. The only reason DCP mandates Web DIDs is for interoperability. There has to be at least one common DID method if interoperability is required. Additional DID methods can easily be supported in the future, if requirements present themselves.
There is currently no specification for "EUDI Business Wallets," so this is just speculation and therefore not something that can be included in design considerations for current protocol work.

I did not talk about DSP anywhere. The DCP uses DID for service discovery, precisely at step 6 of the presentation flow: "The Verifier obtains the client's Credential Service endpoint address using the DID document as described in Section 5.2 Credential Service Endpoint Discovery". Thus, alternative methods have to support such service discovery.

Nowhere does the article assert that Offers and Agreements belong to the "identification layer".
The statement, "In a DSP-based data-exchange, the underlying agreement (and offer) can be resolved from the connected Transfer Process" makes no sense in the context of DSP. The "underlying agreement" and "offer" are not resolved from the "connected Transfer Process." A transfer process is essentially a control channel for data transfer.
DCP and OpenID4VC are very different in how VCs are presented to the provider.

I'm a little confused by this argument. You claim that its a problem of OID4VC, that there is no mechanism to "correlate contract offers and agreements to determine policies". Thus, we are at the identity layer. Or what exactly do you mean with that?

Using the Same Device Flow makes no sense in the context of an enterprise deployment for obvious reasons that should not need further elaboration.

The security assumption here is that the interactions are happening on a single device in the control of an End User (human).

The basic assumption of using OID4VC for M2M communication is, that the End-User Role is fulfiled by a service, instead of a human. Else it wont be M2M. Therefor it makes totally sense to look at the Same-Device Flow and use it for such. When using OID4VC in M2M, the Service being in the role of the End-User can easily run in the same environment as the component holding the credentials for it(the wallet). Its the same approach taken for OIDC in M2M for years already, where a service has direct access to its secrets and can use them to identify in an OIDC flow. The only deviation that is required from the original OID4VP spec is the fulfillment of the End-User role, which is not a Human but a Machine.

[jimmarino]

I think one of the fundamental differences in our view of interactions in a data space is, that in you case the service agents always directly represent the organization, while in our case the service agents act on-behalf of the organizations, using their own identity and the powers they got delegated by the organization, very similar to the way interactions between organizations happen in the physical word. Doing so enables a much broader set of interactions in data spaces. It also is the essential prerequisite to build a system using OID4VC as we propose.

Sorry, but DSP does not work this way. Also, this type of delegation only creates needless complexity and offers nothing that the existing DSP architecture cannot accommodate in a much simpler way. Of course, you can innovate however you see fit, but this is not compatible with DSP and is a proprietary solution.

Nowhere does the article assert that Offers and Agreements belong to the "identification layer".
The statement, "In a DSP-based data-exchange, the underlying agreement (and offer) can be resolved from the connected Transfer Process" makes no sense in the context of DSP. The "underlying agreement" and "offer" are not resolved from the "connected Transfer Process." A transfer process is essentially a control channel for data transfer.
DCP and OpenID4VC are very different in how VCs are presented to the provider.

I'm a little confused by this argument. You claim that its a problem of OID4VC, that there is no mechanism to "correlate contract offers and agreements to determine policies". Thus, we are at the identity layer. Or what exactly do you mean with that?

You are misunderstanding what an Offer and Agreement are in DSP. Also, the DCP specification is quite clear on the notion of consent as it defines a way to associate fulfillment of policy constraints with specific claims requirements.

Using the Same Device Flow makes no sense in the context of an enterprise deployment for obvious reasons that should not need further elaboration.

The security assumption here is that the interactions are happening on a single device in the control of an End User (human).

The basic assumption of using OID4VC for M2M communication is, that the End-User Role is fulfiled by a service, instead of a human. Else it wont be M2M. Therefor it makes totally sense to look at the Same-Device Flow and use it for such. When using OID4VC in M2M, the Service being in the role of the End-User can easily run in the same environment as the component holding the credentials for it(the wallet). Its the same approach taken for OIDC in M2M for years already, where a service has direct access to its secrets and can use them to identify in an OIDC flow. The only deviation that is required from the original OID4VP spec is the fulfillment of the End-User role, which is not a Human but a Machine.

The Same Device Flow in OID4VC requires a single device. If that requirement is removed, the security context is dramatically altered, and the flow is open to additional attack vectors. Placing an arbitrary and undefined requirement that the connector and credential service must be "in the same environment" also makes no sense.

Going back to my previous point, to have a constructive discussion, please show us actual working code: a connector that supports DSP using a non-modified OpenID4VC identity implementation that handles the target EDWG use cases.

[PeterKoen-MSFT]

@wistefan In addition to what Jim already wrote I would like to point out that the Same Device Flow is not feasible for dataspaces for several reasons:

• Regular validation of claims: policies on contracts might have to be inspected at multiple times, depending on the sensitivity of the data it might be necessary to check the validity of claims on a regular basis, even after the contract has been agreed. (e.g.: a contract is setup to provide a monthly set of data, but before data can be send the validity of claims needs to be checked - this needs to happen automatically without an end-user being able to provide consent via their wallet at that point in time)
• Long running data sharing contracts: data sharing contracts might be valid for a very long time and between the negotiation of a contract and the execution of the contract can be an indefinite amount of time. It is possible that the end-user who initiated the contract negotiation is no longer a valid representative of the organization once the contract is being executed.
• Legal binding of the organization: the organization will be responsible for the contract and the validity of the claims even if the end-user changes employer or role within the organization, therefore tying the contract to the end-user credentials would break the contract in those cases.
• Resiliency: in an enterprise scenario the connector components need to be deployed on multiple nodes in multiple geographies, providing failover, disaster recover and high availability features which might require multiple machines to be involved in the operation of the service endpoint
• Scaling: in a high scale enterprise scenario the connector components might have to be deployed over multiple device in a cluster acting as one virtual endpoint.

As you can see there's plenty of practical reasons as well to not bind the credentials of the contract negotiation to the end-user credentials, but rather treating the end-user merely as an attribute of the contract.

Also in current, paper based contracts it is the organization that is the legal owner of the contracts, the end-user, acting as an agent of the organization is only an attribute in those contracts, not the legal owner of the contract. In the case of dataspaces the agent is the software agent, not the human end-user.

[wistefan]

@jimmarino

Sorry, but DSP does not work this way. Also, this type of delegation only creates needless complexity and offers nothing that the existing DSP architecture cannot accommodate in a much simpler way. Of course, you can innovate however you see fit, but this is not compatible with DSP and is a proprietary solution.

Could you please point me, where in the specification such delegation is prohibited or incompatible?

As an example of a use-case, that could be well served with that approach: An organisation operates various edge devices(for example renewable power plants). In order to better work, those edge devices should use environmental and meterological data(at there location), provided by another entity in the space. With the DCP, the data for all those devices would have to flow through the central organization and then needs to be distributed to the edge devices. With delegetion, every edge devices can access the data it requires independently from the central organization directly from the provider, reducing the load at the organization and making it more resilient by removing a central point of failure.

You are misunderstanding what an Offer and Agreement are in DSP. Also, the DCP specification is quite clear on the notion of consent as it defines a way to associate fulfillment of policy constraints with specific claims requirements.

May you enlight about my misunderstandings? An offer is A concrete Policy associated with a specific Dataset.. An agreement is A concrete Policy associated with a specific Dataset that has been signed by both the Provider and consumer Participants. An Agreement is a result of a Contract Negotiation and is associated with exactly one Dataset.. In the context of Contract Negotiation and Transfer Process, the Offer is the proposed policy from one participant in the negotiation, while the Agreement is the (potentially deviating) Policy that both sides agreed on, that will be used during the Transfer Process.
Once the Transfer Process is started, authentication/authorization is not further specified, but (as far as I understand) depending on the implementation of the transport channel. How the authentication is used to identify the correct Policies and enforce them with the required claims is also not further specified in the DSP. If it is, please point me to that place.

The Same Device Flow in OID4VC requires a single device. If that requirement is removed, the security context is dramatically altered, and the flow is open to additional attack vectors. Placing an arbitrary and undefined requirement that the connector and credential service must be "in the same environment" also makes no sense.

In the "Same Device Flow" the End-User(in M2M, the Service Agent) and the Wallet reside on the same device. Which for M2M use cases is easy to achive and the most likely case. When each Service Agent controls its own Identity and holds its own Credentials, they do not need to rely on centralized Services, that might be deployed on different devices.
This is also not an arbitrary and undefined requirement, but the reality of enterprise systems. Depending on the implementation, Wallet and Service could(and most likely would) run in the same cluster/environment, which is always been treated as a single logical entity, not broken down to individual devices. As far as I understand, DCP acts under the same assumption of Credentials Service, Security Token Service and Participant Agent running in the same environment. It at least does not specify additional security mechanisms for the interactions between those 3.

Going back to my previous point, to have a constructive discussion, please show us actual working code: a connector that supports DSP using a non-modified OpenID4VC identity implementation that handles the target EDWG use cases.

Repeating that request doesn't help. You will claim that letting the End-User beeing represented by a Service Agent is a modification anyways. However, where can I find the documentation of the target use cases? I'm open to describe you a solution, based on OID4VC.

@PeterKoen-MSFT

Regular validation of claims: policies on contracts might have to be inspected at multiple times, depending on the sensitivity of the data it might be necessary to check the validity of claims on a regular basis, even after the contract has been agreed. (e.g.: a contract is setup to provide a monthly set of data, but before data can be send the validity of claims needs to be checked - this needs to happen automatically without an end-user being able to provide consent via their wallet at that point in time)

That's a requirement, independently from the identity protocol. The base-assumption is still, that the End-User role will be fulfilled by a Service Agent, not a Human. Therefor it can easily be done and repeated at every time during the contract.

Long running data sharing contracts: data sharing contracts might be valid for a very long time and between the negotiation of a contract and the execution of the contract can be an indefinite amount of time. It is possible that the end-user who initiated the contract negotiation is no longer a valid representative of the organization once the contract is being executed.

This is a problem, that equally exists for DCP. Every Credential can expire or become invalid during the runtime of a contract. The solution is usually Credentials Revocation Lists, which can (and should) be checked by both protocols regularly.

Legal binding of the organization: the organization will be responsible for the contract and the validity of the claims even if the end-user changes employer or role within the organization, therefore tying the contract to the end-user credentials would break the contract in those cases.

I did nowhere argue for tying the contract to an individual. An individual(or service agent) might be entitled by the Organization to agree on the contract on behalf of the organization. Thats the same flow as in the physical world, where a contract also does not become invalid, just because the signer changes organizations. The indiviudal or service always needs to present its entitlement, together with potential additional credentials. In this case, it also can just be replaced by other services or individuals to use the contract.

Resiliency: in an enterprise scenario the connector components need to be deployed on multiple nodes in multiple geographies, providing failover, disaster recover and high availability features which might require multiple machines to be involved in the operation of the service endpoint
Scaling: in a high scale enterprise scenario the connector components might have to be deployed over multiple device in a cluster acting as one virtual endpoint.

In enterprise scenarios, the clusters are treated as single logical entities. From the perspective of the protocol and the verifiere, they act as a single device. And no, that does not introduce new attack vectors to the protocol. The security between those nodes and potentially regions belongs to the operation of the cluster, not the identity protocol. Scaling it out for resiliancy or performance therefor can be achieved the exact way it would be with the DCP. In contrast, the delegation of rights to sub-services that we can do with OID4VC is a clear benefit in such scenarios. In DCP, where services always act under the identity of the organization, the centralized credentials service needs to be available and used in any Credentials Exchange(therefor building a Single Point of Failure and performance bottleneck). In OID4VC, the central identity only needs to be used for issuing entitlements to the sub-agents. Those then can be used independently(and therefor more resiliant and easy to scale) from the central service.

[JuanjoHierro]

I believe that you @PeterKoen-MSFT and @jimmarino are assuming things working in a way that is not the way they would work in data spaces where users (natural persons, for example employees or customers of a given organization, but even also software agents and devices owned/linked an organization) are able to become direct consumers of data services offered by any provider.

In our vision, which is best served using OID4VC, an organisation P acting as provider of some given data services can establish a contract with organisation C interested in that users linked to its organisation can consume such data services. Users "associated with" organisation C can be employees or customers of organisation C, but can also be software agents linked to that organisation, or devices deployed in the field that are owned by that organisation (organisation C).

When organisation C establishes the contract with provider P, it becomes a trusted issuer of the credentials used in the enforcement of policies defined for data services exposed by provider P (specification of these credentials is one essential characteristic of the given data services). As a result, organisation C can issue those credentials to users associated with its organisation, based on its own criteria. The beauty of the model is that provider P doesn't need to know a) how many users are linked to organisations C, nor b) what is the criteria organisation C has used to issue credentials to each of its users. It simply needs to verify that the given user trying to access a data service: a) owns credentials requested for the data service, b) those credentials were issued by an organisation that has a valid contract in place, therefore entitled to issue the given credentials to potential users, c) that organisation remains being a trusted participant in the data space.

Let's illustrate this with an example: Provider P may be the provider of a "Parks & Garden Maintenance" product. This product offers a number of data services related to maintenance of parks and gardens in cities. This product is served from the Cloud and is offered to Cities all around the world.

A city that contracts this product from provider P, has to deploy, in the parks that it wants to maintain, a number of IoT devices (following specifications of compatible sensors the "Parks & Garden Maintenance" product has published). Some of these devices will deliver measurements about temperature and pollen level to the backend of the "Parks & Garden Maintanance" product. There will be also IoT-enabled devices for managing watering of grass, trees and other plants in the parks/gardens.

The product comprises services to check pollen level in zones of a given park, but also monitor and manage the status of watering devices the owner of the park deploys. This product may be defined (and this is an intrinsic characteristic of the product) so that it distinguish between credentials identifying "gardeners", credentials identifying "park visitors" and credentials identifying "pollen sensors", "temperature sensors" or "watering devices". Also an intrinsic characteristic of the product are the policies applicable, e.g., both park visitors and gardeners can check temperature and pollen levels in zones of a park, while only gardeners can check and manage the status of watering devices, for obvious reasons. Last but not least, it is important that sensors and watering devices owned by the city are the only ones that can connect to the backend of the "Parks & Garden Maintenance" product.

A given organisation C (e.g., a city) may at some given point of time close a contract with provider P. That will mean that organisation C will become trusted issuer of credentials identifying "gardeners", "park visitors", "pollen sensors", "temperature sensors" or "watering devices". This will allow it to issue credentials identifying gardeners to city servants (or employees of subcontractors) that work as gardeners, while it may issue credentials identifying park visitors to citizens or tourists visiting the city. It may also issue any of these credentials to some software agents run by systems within the smart city. Last but not least, by issuing credentials "pollen sensor", "temperature sensor" and "watering device" to the devices it deploys, it secures that only the devices it owns and has deployed are the ones exchanging with the "Parks & Garden Maintenance" system backend.

The support of this kind of use cases, would make data spaces enablers of a new era where product providers can emerge and offer data services that organisations can integrate into their map of systems so that a) users within a organisation can access data services, internal or external, in a seamless manner, and b) organisations remain responsible of managing their users, sovereign on decisions who can access what (also releasing providers of the complexity of managing users).

[JuanjoHierro]

I believe that the clarification by @PeterKoen-MSFT is quite relevant in this whole debate

I believe that there is some misunderstanding on a few critical design choices for IDSA Dataspace Architecture. Let me provide some additional detail which will clarify the article and probably strengthen your understanding of what an IDSA Dataspace is and it will provide some background information on the design decisions for the protocols.

...

In Dataspaces, as understood by IDSA (IDSA Manifesto & IDSA Rulebook) it's organizations that need to share data with each other in a fully automatable way. It does not include the human end-user layer. After data is shared it is managed by organizational Data Management Systems. Users interact with Data Applications, which in turn interact with the Data Management Systems. Actors in Dataspaces are Software Agents representing the organization participating in a Dataspace.

So, essentially, DCP is designed for data spaces with such restricted scope. It would not be appropriate for data spaces where:

• Transactions are not limited to the transfer of datasets but cover also the invocation of services for processing input data (using Big Data or AI algorithms), triggering actuations based on input data, or for the interpretation or visualization of data.
• Not only legal persons (from now on, organizations) but natural persons (humans) can participate as direct users of data services in a data space. Going further, devices or software agents, sometimes many of them owned by a given organisation but with different identities, can also participate as direct users of data services.

OID4VC come to the rescue for these kind of data spaces, while could still work for data spaces that are limited to B2B transfer of data.

We should foster that projects take informed decisions about what protocols are more suitable for their goals, based on an accurate description of what is supported and what is not. That is why we welcome this whole debate.

[jimmarino]

@wistefan

I think one of the fundamental differences in our view of interactions in a data space is, that in you case the service agents always directly represent the organization, while in our case the service agents act on-behalf of the organizations, using their own identity and the powers they got delegated by the organization, very similar to the way interactions between organizations happen in the physical word. Doing so enables a much broader set of interactions in data spaces. It also is the essential prerequisite to build a system using OID4VC as we propose.

Sorry, but DSP does not work this way. Also, this type of delegation only creates needless complexity and offers nothing that the existing DSP architecture cannot accommodate in a much simpler way. Of course, you can innovate however you see fit, but this is not compatible with DSP and is a proprietary solution.

Could you please point me, where in the specification such delegation is prohibited or incompatible?

As an example of a use-case, that could be well served with that approach: An organisation operates various edge devices(for example renewable power plants). In order to better work, those edge devices should use environmental and meterological data(at there location), provided by another entity in the space. With the DCP, the data for all those devices would have to flow through the central organization and then needs to be distributed to the edge devices. With delegetion, every edge devices can access the data it requires independently from the central organization directly from the provider, reducing the load at the organization and making it more resilient by removing a central point of failure.

The above exchange goes to the heart of the problem. You are confusing and conflating a number of architecturally distinct issues:

• The misunderstanding we are discussing in this specific context is DSP, not DCP.
• You confuse the notion of a participant and participant agent, and how the two are related. There is no delegation at the control plane level (it is, in fact, not needed, see my point below). Participant agents always act under the identity of the participant. This is enshrined as a fundamental architectural principle in DSP.
• Contract agreements are always between exactly two participants. Data is exchanged between systems under the control of those two parties. A third party does not enter as a participant in this relationship, because: (1) it is needlessly complex; and (2) it breaks the notion of data sovereignty. For example, a cloud provider hosting a participant's connector does not directly enter into the exchange as a participant. There may be policy constraints that determine which type of cloud provider or infrastructure is required for data exchange, but the cloud provider does not act as a party in the relationship.
• You conflate the role of a control plane vs a data plane. The data plane handles the flow of data, not the control plane, and has nothing to do with DCP, which is the identity system used in the control plane.
• You confuse delegation with distribution. An organization does not delegate data sharing to independent software agents with their own participant identities. It distributes the data plane to the edge. In the example above, a contract agreement is negotiated by the control plane between exactly two participants with exactly two identities. Data may be transferred by a distributed data plane comprised of many thousands of edge devices (although in most real-world industrial systems, one would never allow an external partner to connect to its edge devices directly).
• You conflate the notion of dataspace with system (or human) identities. The IoT devices in the above example may have their own identities managed through a technology like SPIFFE/SPIRE, but they certainly do not have a dataspace participant identity.

I could continue to discuss your other claims point by point, but that would not be productive because the fundamental assumptions about how DSP works are incorrect.

Going back to my previous point, to have a constructive discussion, please show us actual working code: a connector that supports DSP using a non-modified OpenID4VC identity implementation that handles the target EDWG use cases.

Repeating that request doesn't help. You will claim that letting the End-User beeing represented by a Service Agent is a modification anyways. However, where can I find the documentation of the target use cases? I'm open to describe you a solution, based on OID4VC.

Unless you show actual working code, we will talk in circles. Take a DSP implementation and implement the protocol message flows using one of the two unmodified OpenID4VC flows. The EDC MVD project is extensible, and you can easily remove the DCP-based Identity Hub for this purpose. Both the DSP and DCP specifications are designed in the context of multiple implementations. Without code to back up your assertions, you will gain little traction convincing those communities.