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. |
| The verifier also operates a Participant Agent that engages with the holder agent. When it receives a request, it will resolve the holder’s DID document and through this resolve the endpoint for the holder’s Credential Service. It will then send a request for a Verifiable Presentation to the Credential Service, which includes the access token received from the holder’s agent. The participant agent will then match the credentials returned in the Verifiable Presentation against the policy constraints associated the original dataspace request. | ||
|
|
||
| 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.
There was a problem hiding this comment.
From those lines:
- https://github.com/eclipse-dataspace-protocol-base/DataspaceProtocol/blob/main/specifications/common/introduction.md?plain=1#L5
- https://github.com/eclipse-dataspace-protocol-base/DataspaceProtocol/blob/6825362b5f97d4b9a306c8fc8c67ab1597c714c0/specifications/common/terminology.md?plain=1#L51
- https://github.com/eclipse-dataspace-protocol-base/DataspaceProtocol/blob/6825362b5f97d4b9a306c8fc8c67ab1597c714c0/specifications/catalog/catalog.protocol.md?plain=1#L149
I understand that DSP specifies the Messages and the sequence of those Messages with state-machines.
How are those messages exchanged, how are proofs and proofs presentations done are out of scope and HTTP bindings are an example, right ?
To my understanding, one could implement DSP over GRPC or SMTP, no ?
There was a problem hiding this comment.
Please take a closer look at the DSP specification. The HTTP bindings are marked as normative and also verified by the TCK. Someone could define a binding to another protocol, but HTTP is mandatory for interoperability.
| This process enables the issuer entity to issue a verifiable credential to the credential store of the organization. | ||
|
|
||
| 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.
4 participants
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