-
Notifications
You must be signed in to change notification settings - Fork 2
update scenario section #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
update scenario section #6
Conversation
Hi @ticapix , thanks for activly engaging in this work. Your contribution will be reviewed and discussed here and during our meetings. Please keep in mind that we do have our contributing guidelines which ask for an issue first, before creating a PR. If you could provide a justification for your proposed changes, that would make it a lot easier to assess your contribution. |
The concept is called decentralized identities, right? Why use another term in the document? Decentralized Claims is the term used in EDWG (where you are involved) and thus should, because of the relation, be referenced here. I'd suggest to open an issue in the DCP project to discuss this terminology aspect.
We discussed this extensively in #4 |
### Step 1: Establishing Decentralized Identities | ||
Decentralized identities form the backbone of trust in this ecosystem. Company A and Company B, each possess their own decentralized identifiers (DIDs), which are unique representations of their identities within the dataspace. These DIDs are coupled with verifiable credentials issued by trusted entities, such as regulatory authorities or certification bodies. | ||
### Step 1: Establishing Decentralized Identifiers | ||
Decentralized identifiers for policies, claims and evidence for the participating entities, materials, products, production site, ... form the backbone of trust in this ecosystem. Company A and Company B, each possess their own decentralized identifiers (DIDs), which are representations of their unique identities within the dataspace. These DIDs are coupled with verifiable credentials issued by trusted entities, such as regulatory authorities or certification bodies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not in scope of this document.
|
||
For example, Company A might possess credentials verifying its compliance with ISO 14001 environmental management standards, while Company B holds credentials confirming its adherence to industry specific safety protocols. | ||
For example, using the Eclipse Conformity Assessment Profile, Company A might possess credentials verifying its compliance with ISO 14001 environmental management standards, while Company B holds credentials confirming its adherence to industry specific safety protocols. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence is barely readable, please reformulate. The added half-sentence should be a dedicated paragraph to explain the relation between both.
|
||
### Step 2: Exchanging Verifiable Credentials | ||
To share data related to the DPP, the two companies exchange claims supported by their verifiable credentials. Using a protocol such as the Eclipse DCP, Company A can present claims that demonstrate the environmental sustainability of its production processes without exposing sensitive proprietary data. Similarly, Company B can substantiate its claims regarding safety compliance in a secure, cryptographic manner. | ||
To share data related to the DPP, the two companies exchange claims and evidence supported by their verifiable credentials. Using a protocol such as DCP and OID4VC, Company A can present a verifiable credentials which contains one of more claims and evidences that demonstrate the environmental sustainability of its production processes. Similarly, Company B can substantiate its claims and evidences regarding safety compliance in a secure, cryptographic manner. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the justification for evidence here?
@ticapix most edits are on evidence and not on identities vs. identifiers. What is that, where is it described and why do we need this in this paper? |
Because identities and identifiers are 2 different concepts. An identity refers to characteristics by which a person or thing is recognizable, and those characteristics are expressed as claims or evidence. "I'm Pierre" is a claim. My state issued ID card is an evidence. Those claims and evidence are in the payload of the Verifiable Credentials (VC), in the The VC's payload is not limited to claims and evidence on identities and could be about a dataset, a service, a certification, pictures of cats, ... Then we have protocols: WACI-DIDComm, CHAPI, DCP, OID4VC, ... to exchange credentials. The claims, evidence, whatnot, ... are the payload inside the credentials which are exchanged (issued, presented). Comparing protocols, which I understood is the goal of the document, should focus on comparing protocol features, independently of the name of the protocols. The "Decentralized Claim protocol" is as much about claims than SMTP is about newsletters. Finally, the identifiers. An identifier identifies an entity/object/asset/resource/claim/evidence/, which can be an identity. An identity is not decentralised. It's the identifier, which, in some case, due to the associated governance for its issuance/update/deletion/revocation, can be decentralised. |
In the context of #8:
Replace “claims protocol” by “credential exchange protocol” everywhere: Both protocols do the same “exchanging verifiable credentials (VC)”.
Replace “decentralised identity(ies)” by “decentralised identifier(s)” : An identity is not decentralised, nor centralised. It’s the resolution and governance of the identifiers of the identity which can be decentralised.
Ex: I have one identity and several identifiers, some of my identifiers are issued by the government, some are a public keys on a blockchain.
Add OID4VC where Eclipse DCP is mentioned because both can be used for M2M.