Replies: 35 comments 2 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
This is btw not an issue and should be changed to a discussion. @ssteinbuss we should enable discussions in this repo, WDYT?! |
Beta Was this translation helpful? Give feedback.
-
|
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: 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. 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
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
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
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
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. 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. |
Beta Was this translation helpful? Give feedback.
-
Dear @ccsr, |
Beta Was this translation helpful? Give feedback.
-
|
EDC committer, DSP committer, and DCP Editor here to further elaborate on what @PeterKoen-MSFT has said:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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.
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?
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. |
Beta Was this translation helpful? Give feedback.
-
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.
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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:
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. |
Beta Was this translation helpful? Give feedback.
-
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.
May you enlight about my misunderstandings? An offer is
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.
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.
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.
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.
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
I believe that the clarification by @PeterKoen-MSFT is quite relevant in this whole debate
So, essentially, DCP is designed for data spaces with such restricted scope. It would not be appropriate for data spaces where:
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. |
Beta Was this translation helpful? Give feedback.
-
The above exchange goes to the heart of the problem. You are confusing and conflating a number of architecturally distinct issues:
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.
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. |
Beta Was this translation helpful? Give feedback.
-
In DSP/DCP you would model such a data-sharing arrangement as follows:
This is a flexible and straightforward approach that also scales well. |
Beta Was this translation helpful? Give feedback.
-
|
From @PeterKoen-MSFT's characterization of a data space:
This narrow definition of a data space as just a "technical design pattern" limited to organizations as direct participants is flatly contradicting the understanding of several not unimportant initiatives:
Of course, one can work under this limited assumption and the resulting (kind of) 4-corner architecture may work very well in certain contexts where such an architecture is the best approach relative to some non-functional requirements of the use case. However, there are other use cases (like citizens participating in a building permit approval process, residents directly engaging themselves in a smart city data space, owners of PV installations participating directly in an energy data space, where this fundamental assumption no longer holds. As a direct consequence of this failure to recognize these other contexts, the protocol choices will no longer be the best choices with regards to NFRs relevant for these contexts -- like having a sovereign participant agent instead of having to rely on someone else providing me with a that piece of software where I need to log in, pay service fees, and am bound to their platform -- just because the architecture forces me to do so. |
Beta Was this translation helpful? Give feedback.
-
In the example, IoT devices are owned by C. That is actually a requirement. The "Parks & Gardens Maintenance (P&GM)" product provider offers an application as a services comprising multiple services. A City C that contracts that product, will deploy the IoT devices that are compliant with provider P specifications, and configure them to connect to the P&GM backend. Based on data provided from temperature and pollen sensors, for example, the P&GM will be able to offer different services to gardeners and park visitors of city C. Obviously, the IoT devices are owned by the city, which ultimately manages an assignment of identity to them during the provisioning. Connection between those IoT devices and the P&GM backend is secured because each device is issued verifiable credentials they can authenticate with against the P&GM backend, and here it is when we see OID4VC required since identity is different per device, which will not be managed at the organization level.
This sounds interesting. So ... are you saying that DCP is mostly focused in the authentication of organizations during the contract negotiation phase and OID4VC (or any other authentication protocols) could be then used for the authentication of users linked to the contracting organization, being these users the ones which will ultimately carry out the transfer of data or the invocation of services after contract is established? |
Beta Was this translation helpful? Give feedback.
-
See DSP 9.1.1.1 Control and Data Planes. It states: The specification of data plane interfaces and interaction patterns are not in scope of this document. |
Beta Was this translation helpful? Give feedback.
-
We know that DSP is limited to the control plane. Our understanding is also that DSP protocols are not bound to DCP. As an example, the consumer of data/services offered by a given provider doesn't need to use DCP for authenticating in order to start invoking DSP operations exported by the provider (e.g., for querying its catalog, or starting a negotiation). Question was whether DCP intends also to be just limited to the control plane. It would make sense to me since, as explained, is not suited for some fundamental interaction cases to be supported in data spaces. Still as protocol for exchange of credentials to be able to invoke operations associated to DSP protocols (e.g., to be able to invoke operations linked to contract negotiation), we believe OID4VC is appropriate. Furthermore, we believe it has also several advantages over DCP. |
Beta Was this translation helpful? Give feedback.
-
|
That was already answered by @jimmarino above:
DCP is a specification project and (together with the DSP) answers the need to have a protocol stack for dataspaces according to definitions following ISO20151, IDSA, and EDWG. This is the intended scope! If in the future, someone wants to adopt DCP and build an implementation based on it in another context (e.g. authorization in a data plane), I do not care.. This is not in the scope of a dataspace*. You also don't want to force every provider of data exchange solutions to use OID (at least I really hope so). * And we are back to the definitions of a dataspace. However, this is a useless discussion in a GitHub issue like this! That's why I'll go with Jim and his conclusion from here on. |
Beta Was this translation helpful? Give feedback.
-
Well ... thank you for qualifying this thread as "useless" :-). We took the step of creating an issue and commenting on the original article because that is what @ssteinbuss asked for in his original post on LinkedIn :-) The vision of what are the main characteristics a data space should support is crucial. Regarding that vision, it seems like some people like @PeterKoen-MSFT claim that IDSA-compliant dataspaces will be only for exchange of data between organizations, not involving users of those organizations directly in that exchange. Looking at the answers from @jimmarino, it seems like he may have a bit wider perspective, as he seems to argue DCP just need to be used for authentication in connection to DSP exchanges. It would be good to know which of the two visions IDSA wants to go for. An interesting question is also whether the IDSA Community wishes to bind/lock DSP to DCP. DSP can perfectly work also with VC exchange protocols different than DCP for authentication when querying the catalog or at contract negotiation time, concretely OID4VC. We are demonstrating that in the implementation of the FIWARE Data Space Connector (@wistefan provided the link to the repo on GitHub if anyone wish to check). Therefore, we don't see such locking as per today. Furthermore, if DSP evolves to get locked to DCP, that would be a severe mistake. It would limit adoption of DSP. It would be good to clarify whether that is the direction the IDSA Community wishes to take. I hope it is not. People talk about control plane and data plane but while it is clear that certain functions are placed in the "control plane" and others in the "data plane", there are other functions which are not that clear where they are placed. As an example, the authentication required by agents involved in the exchange prior to their actual exchanges. Or authorization management (enforcement of policies) during the exchange. Will you qualify those functions as belonging to control plane or data plane? One thing is clear: identity management and authorization is handled at two levels within data spaces:
Identities of parties may be different in these two levels. Using verifiable credentials at the two levels seems adequate. In principle, the protocol for exchange of credentials may be different in these two levels, even though is preferable to have a single one if it fits all needs. We see DCP brings important limitations at both levels, while OID4VC bring advantages at the two. |
Beta Was this translation helpful? Give feedback.
-
|
@JuanjoHierro this is not what I wrote. I wrote that having a discussion on the definition of dataspaces is useless in this issue. And until there is not a common understanding on dataspaces, having a further deep dive on feedback and details on the actual topic (OID & DCP) - on which feedback was requested - doesn't make sense after we have these different positions visible now. |
Beta Was this translation helpful? Give feedback.
-
|
@JuanjoHierro I think a few clarification points are in order.
Myself, @PeterKoen-MSFT, @mspiekermann, and @ssteinbuss (among others) are in perfect alignment. As Markus and I have tried to explain, the problem is with your characterization of what we are saying. I believe the root issue is that the four of us are operating on the basis of the terminology and conceptual model defined by the DSP Specification, and you are not. In addition, not only is your approach different than the concept of a dataspace as outlined by DSP, but you are also conflating terms and confusing architectural concepts, which makes it impossible to have a clear discussion. That said, your characterization that the DSP conception of a dataspace is unable to account for human interactions is not accurate, as I outlined in the solution to the parks scenario. We all believe that humans exist and take actions that have an effect in a dataspace, such as initiating a contract negotiation request or a transfer process request. Humans may even be required to approve a contract negotiation through a manual workflow. DSP accounts for these types of interactions by externalizing them from the core protocol. In other words, as Peter has explained previously, they are not directly inserted into DSP message exchanges. This is part of the asynchronous design of the DSP state machine, which is an automation that can overlay manual workflow processes. Humans can also receive data in the DSP model. As several of us have pointed out, you are confusing the control and data plane. A transfer process in DSP is a control plane concept, which differs from the actual flow of data over the wire ("the wire protocol"). The latter is the data plane. Wire protocols typically define specific authentication mechanisms, for example, an OAuth flow or another token-based scheme. As Markus mentioned, DSP does not concern itself with this except to provide a mechanism for transporting metadata and an initial auth token through the control plane (in the data address construct) to bootstrap the wire protocol. The solution I proposed for the parks scenario was to use a streaming wire protocol to exchange data. The sensor data would be fed and processed before being sent to the provider's app batch input using a streaming protocol. The app could perform additional processing. Users would then log into the app (perhaps using OpenID4VC or something else) and access the data. The above scenario, which involves humans, is handled by DSP. However, at the DSP message exchange level, human interactions and OpenID4VC are not directly involved. This scenario is no different than most other B2B scenarios. Data is transferred using M2M exchanges (DSP and the wire protocol), and humans (or applications) authenticate to access the transferred data from some persistent store.
The connector code in the repository you mentioned is proprietary and not open source. However, looking at the code that is open source, I do not understand how you claim it is compatible with DSP. Does it support the HTTP message exchanges as defined in the DSP specification? How many of the TCK test cases does it pass? Do you have publicly available DSP verification tests? If you have not looked at the official TCK, we would be happy to help walk you through creating an automated test setup that can be integrated with a CI pipeline to verify the Fiware connector (assuming it is open-sourced). There are three projects I am aware of using it and others that have plans to in the near future. The code also does not follow the standard OpenID4VC flows. For example, it introduces a proprietary endpoint, is not integrated into DSP message exchanges, and appears to require manual intervention to copy and paste auth tokens in the demo. Before posting references to code, please make sure they are open source and reasonably follow the specifications they claim to support. Another point of clarification is that DSP is governed by the Eclipse Dataspace Working Group (EDWG). An official statement on the relationship between DSP, OpenID4VC, DCP, and Trust Frameworks was just approved by the EDWG and can be found here. |
Beta Was this translation helpful? Give feedback.
-
The connector is open source, just the implementation of the DSP protocol is not yet open source, since UPM wants to do some clean ups first. However, if you are interested in the details, I'm sure caparicio-esd will help you.
The implementation supports the HTTP-Binding for Catalog and Transfer Process. For the Contract Negotiation, we support the messages and state machine, but provide an alternative binding at the moment. We currently do not plan to invest effort in any of the test cases, since they do not provide any value for us at the moment. However, in order to prove integration with OID4VC, they are not required.
You are right that the demo currently uses a simplified flow, that makes it easier to follow. Sorry, was not aware of that anymore. However, standard endpoints are supported. We are currently working on updating them to the latest draft version of OID4VP. The conformant flow(that is supported by the connector) would be: ---
config:
theme: default
---
sequenceDiagram
box Participant A
participant Service
end
box Participant B
participant Verifier
participant ApiGateway
participant PDP
participant Rainbow
end
Service ->> Verifier: Initial interaction(start flow)
Verifier -->> Service: Authorization Request(Presentation Definition)
Service ->> Verifier: Authorization Response(vp_token)
Verifier -->> Service: Responds with access_token
Service ->> ApiGateway: DSP request with access_token
ApiGateway -->> ApiGateway: Verify access_token
ApiGateway ->> PDP: request policy decision
PDP -->> ApiGateway: respond decision
ApiGateway ->> Rainbow: forward DSP request
In this case, the "Service" would take the role of
What do you mean with "not integrated into DSP message exchange"? The Authentication/Authorization is not tightly coupled to the DSP implementation by intention. It sits in front of the HTTP-Endpoints, thus is involved in every step of the message exchange.
Thanks for sharing that. However, the statement is not fully correct. The Verifiable Credentials issued by DCP and OID4VCI are only interoperable if they follow the issuer restrictions of the DCP. Thus, all Credentials issued by DCP can be used in OID4VC, but not all Credentials issued by OID4VCI can be used in DCP. |
Beta Was this translation helpful? Give feedback.
-
DSP and DCP are specifications governed by the Eclipse Foundation. Key benefits of the Eclipse specification process are a transparent and level playing field for participants, no vendor lock-in, and objective criteria for determining compatibility in the form of Technology Compatibility Kits (TCKs). In this world, an implementation is compatible if it passes the automated test suites (TCKs), which verify normative statements in the specification. If an implementation does not pass a TCK, it is not compliant, and the specific normative statements that are not supported are known. This helps foster a vibrant ecosystem by providing a solid foundation for interoperability and clarity to adopters. In contrast, the world of pseudo-standards is characterized by a lack of transparency and openness, where implementations decide whether they are "compliant" based on arbitrary whim. Another term for this is vendor lock-in. In this case, a vendor can be a commercial organization or a project that develops and manages a codebase. This world is similar to the one where vendors claim code is "open source," but it is not distributed under an actual open source license, or parts of the code are closed-source. Again, it is based on arbitrary whim. This world is what you are asking us to accept. The implementation somehow "supports the messages and state machine" but does not implement the basic APIs or message flows. The bottom line is that implementation is not interoperable with any of the other DSP-based connectors and therefore does not support DSP by any reasonable measure. What you have created is not a DSP implementation but a walled garden. It represents a platform lock-in because it would require every participant in a dataspace to use the same implementation. You seem to be fine with this approach based on your statement that, "We currently do not plan to invest effort in any of the test cases, since they do not provide any value for us." On its face, that is fine, but don't claim the implementation "supports" DSP. That is a disservice to the interoperability ecosystem that Eclipse, IDSA, and other organizations are trying to build.
Catena-X investigated the same flow (and others) over three years ago (as well as other dataspaces and IDSA). The above approach:
The above flow suffers from these problems because you have not worked through a real-world dataspace use case where credential requirements vary per request context, do not have actual end-to-end working code, and because you do not thoroughly understand DSP and DCP. Again, look at the EDC MVD, which clearly lays out the use cases and has answers to all of these issues highlighted above. It's pretty clear that you want the benefits of claiming DSP compliance and promoting your solution to that community without putting the hard work into interoperability and passing the TCK. It's notable that the organizations accused of developing "proprietary solutions" are doing the opposite and making that investment. At this point, our views on dataspace interoperability, transparency, openness, and what constitutes a good specification are too divergent to bridge the gap. We should let the market decide which approach is more relevant. |
Beta Was this translation helpful? Give feedback.
-
Sorry @jimmarino but your answer only deviates from the topic under discussion that I remind it was: Is DSP (i.e., its protocols: catalog, contract negotiation, transfer process) bound to DCP, or can it be used with other authentication method for the exchange of verifiable credentials such as OID4VC? We have stated that we believe that DSP is not bound to DCP. From our understanding of DSP specifications, none of the DSP APIs dictate any authentication framework. However, in practice, It is expected that they will be used together with some authentication framework. This can be DCP but can be also OID4VC (and probably others). As simple as that. This is what we are saying. If you state that DSP is bound to DCP, therefore DSP APIs can only be used with tokens obtained through DCP, then please make that statement more clear and explain why. If you are able to accept that DSP does not obligue to use DCP, then we can elaborate why we believe OID4VC can do the job better as an authentication framework for DSP (despite using DCP could be also valid for some scenarios). But one step after the other:
As with regards to the topic of what authentication framework can be used for the actual exchange of data or invocation of services, once a contract is established via DSP, I was happy to see that your position was that DCP was not mandated and OID4VC can be used. This is, at least, a nice conclusion. |
Beta Was this translation helpful? Give feedback.
-
Sorry, you are deviating from the conversation at hand. You are erroneously claiming support for DSP when your implementation is in no sense compliant and does not even adhere to the basic DSP APIs. You have also stated that there is no intention to pass the TCK. Claiming DSP support in that context is a disservice to the DSP community, which expects interoperability. No one is claiming that other authentication protocols cannot be used with DSP. In fact, EDC supports centralized OAuth2 based on the client credentials grant. What we are claiming is that OID4VC cannot be used with DSP without creating custom extensions to the OID4VC specification. We are going around in circles. You are obfuscating the fact that the code you referenced is not open source, does not implement DSP, and does not follow the OID4VC specification. Again, either show us working code as we asked, or let's end the discussion and have the market decide whether interoperable solutions based on DSP or walled gardens are better. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @jimmarino, Thanks for your response. You confirm our hypothesis that 1. DSP is not bound to DCP which means we can concentrate on the second step of the discussion now, that is: Can OID4VC be used as authentication framework for gaining the access tokens to use for invoking DSP APIs? Here, in your last comment, you state: "OID4VC cannot be used with DSP without creating custom extensions to the OID4VC specification." We have implemented a verifier that implements OID4VC and whose code is available as open source. We haven't implemented any "custom extensions" to it and it is used for authentication with different APIs, i.e., for obtaining the access token you can then use for invoking those APIs in the context of data spaces: NGSI-LD, TM Forum Open APIs, DSP Catalog API, DSP Transfer Process API, ... May you point out what are the custom extensions we have implemented in you opinion? Last but not least, Stefan brought a elaborated response to the "issues for OID4VC" raised in the original article and in some of the subsequent comments. May you point out which of his responses were unvalid? Perhaps the answer to this question is related to the "custom extensions" you see in our implementation, so we can focus the discussion. |
Beta Was this translation helpful? Give feedback.
-
We are going around in circles, as you are not listening to what we are saying and just repeating the same false claims. Please re-read my last comments and let's have the market decide which approach has more merit. |
Beta Was this translation helpful? Give feedback.
-
|
Folks, especially @wistefan @JuanjoHierro @mspiekermann @jimmarino |
Beta Was this translation helpful? Give feedback.
-
|
Hi Sebastian, There have been several "topics of discussion" that have arisen during this discussion, it would be nice to understand how results from the discussion on each of these three topics will be handled:
|
Beta Was this translation helpful? Give feedback.
-
This is patently not true. No one is making this claim, and the article does not make such a statement. Please, let's refrain from repeating it.
Again, this is not true. Please re-read the discussion and avoid these false claims. I will repeat the main points:
Bottom line: the approach you are advocating is proprietary, and you have failed to provide code that implements DSP, OpenID4VC, much less demonstrate interactions between both. When we pointed out specific technical issues with the proprietary solution that render it inoperable with DSP, they were ignored.
Again, this is not accurate. You have fundamentally misunderstood DSP and DCP. This statement is coming from someone who has designed and implemented large portions of those specifications and the EDC. This has been corroborated by others in this discussion. Please try and understand what we are telling you rather than repeating the same inaccurate claims. If you disagree with the technical approach DSP or DCP has made, that is fine. Please design and build an alternative. In contrast, the article is about those concrete technologies and how they solve specific data sovereignty issues. I'm interested in running code, not marketing platitudes or philosophical discussions on the best definition of a dataspace. If you want to demonstrate that the article has it wrong, show us in code, not words. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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"
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.
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.
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.
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.
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.
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).
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.
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.
Beta Was this translation helpful? Give feedback.
All reactions