RFC040: verifiable credentials #34
Conversation
ishare_openapi_spec_dcp.yaml
Outdated
| Retrieves a list of supported credential types that the issuer can | ||
| provide. More information in the [DCP specification](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#issuermetadata). | ||
| An iSHARE Participant Registry must at minimum issue a Party claim. An iSHARE Authorization Registry must at minimum issue a Data Rights claim. |
There was a problem hiding this comment.
Can we use the correct terms for the credentials here. participantCredentials and dataRightsCredentials
There was a problem hiding this comment.
I don't think we are using these names participantCredentials and dataRightsCredentials. I have updated it and related it to the definitions of credentials on schemas.ishare.eu.
| { | ||
| "id": "https://schemas.ishare.eu/v3/party/schema.json", | ||
| "type": "CredentialObject", | ||
| "credentialType": "PartyCredential", |
There was a problem hiding this comment.
for other roles then PR, it also shows credential type as partycredential.. i think we need per role its own type right
There was a problem hiding this comment.
Not sure I get this. And not sure how we can define the types here. The id clearly resolves to an external schema, but credentialType seems to be a self-defined string that has no clear relationship with this schema other then this file. Let's align how to address.
There was a problem hiding this comment.
i mean the credential type here should match the one that is in the VC schemas that we defined. For example the 4 main types:
Participant Credential
Data Rigths Credential
Identity Credential
Bitstring Status List Credential
and i think we would also need to define the claims credentials as similar to above so they can be referenced
As metadata must make it clear which credential types it can issue.
There was a problem hiding this comment.
Now that I have changed the credentialType names in the schemas this example is in line with the schemas. Each issuer provides its own metadata endpoint on which it exposes which claims it supports. So a PR will support issuance of party and claim credentials, but an AR only of DataRightsCredentials.
No description provided.