update DCP section #11
Conversation
|
There is no EDC section so I changed PR's title |
You are misunderstanding what the STS is. The STS is simply a logical representation of a token generator that is purely internal to a participant acting in a consumer role. I would recommend reviewing the DCP specification before erroneously claiming that the concept of the STS violates the "W3C VC trust model." Also, I don't understand what this has to do with the EDC. |
|
|
||
| This enables the establishment of consent for the release and access to a protected resource. Since the Dataspace Protocol is built on machine-to-machine message exchange patterns for Software Agents (Dataspace Connectors), end-user consent is not applicable. | ||
| This enables the establishment of consent for the release and access to a protected resource. Since the Dataspace Protocol is agnostic of the message exchange protocol, machine-to-machine message exchange patterns is supported with Software Agents (Dataspace Connectors), end-user consent is not needed. |
There was a problem hiding this comment.
this 'agnostic of the message exchange protocol' is unclear, can you please explain.
|
|
||
| During the negotiation of a data sharing contract the participant offering the contract will ask the organization which requests the data sharing contract to provide verifiable credentials that contain proof that the policy is being met. Those claims need to be verified with a verifier to know whether they are to be trusted. | ||
| During the negotiation of a data sharing contract the participant offering the contract will ask the organization which requests the data sharing contract to provide verifiable credentials that contain proof that the policy is being met. Those claims and evidence need to be verified with a verifier to know whether they are to be trusted. |
There was a problem hiding this comment.
Still unclear about this evidence. Please explain and justify. It is not related to this document.
in the context of #8:
update the EDC section to fix principal inconsistencies:
DID stands for identifiers, not identities: only the identifiers can be technically or from a governance PoV decentralised.
An identity is not decentralised.
A DID is not verified, it's resolved. A DID document is not signed and the content can't be verified using cryptographic material.
The "trust" from a DID comes from the governance of the DID method and the associated issuance rules.
A DID resolution depends of the DID method and has nothing to do with the VDR
However a DID can be accepted or not by a recipient by using the VDR.
Unless a quote of the Eclipse DSP spec is provided, DSP is message exchange protocol agnostic.
Also, it seems to me that the DCP workflow being described here is breaking the W3C VC trust model by introducing the STS component, instead of using the VDR for what it's for.
I leave the original authors of this document to appreciate the irony of promoting decentralisation and introducing contradicting evidence from their proposed protocol