Closed matbmoser closed 2 months ago
Was presented in the open planning ⇾ responsible committers are already defined
Ok I am starting to work on this ticket since yesterday. First challenge, make a "valid" CDC and CSC json-ld credentials based on info from semantic hub. I will be linking the tasks to this feature.
Using the schema file we are able to generate this view:
where the schema context can reference to
I have just created an amazing thing:
This python function uses "recursion" to generate a JSON-LD context from a json schema from ANY! Catena-X Aspect model: Example with bom as build:
And this is produced:
I present the first valid JSON-LD credential for Catena-X built in a generic way for any data model:
{
"id": "https://tx-dpp.int.demo.catena-x.net/provider_backend/data/cx:mfg024:prt-30001",
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3c.github.io/vc-jws-2020/contexts/v1",
{
"aspect": "urn:samm:io.catenax.single_level_bom_as_built:3.0.0#",
"schema": "https://schema.org/"
},
{
"@context": {
"@version": 1.1,
"catenaXId": {
"@context": {
"@definition": "The Catena-X ID of the given part (e.g. the component), valid for the Catena-X dataspace."
},
"@id": "aspect:catenaXId",
"@type": "schema:string"
},
"childItems": {
"@container": "@list",
"@context": {
"@context": {
"@version": 1.1,
"businessPartner": {
"@context": {
"@definition": "The supplier of the given child item."
},
"@id": "aspect:businessPartner",
"@type": "schema:string"
},
"catenaXId": {
"@context": {
"@definition": "The Catena-X ID of the given part (e.g. the component), valid for the Catena-X dataspace."
},
"@id": "aspect:catenaXId",
"@type": "schema:string"
},
"createdOn": {
"@context": {
"@definition": "Timestamp when the relation between the parent item and the child item was created, e.g. when the serialized child part was assembled into the given part."
},
"@id": "aspect:createdOn",
"@type": "schema:string"
},
"hasAlternatives": {
"@context": {
"@definition": "Expresses whether the part is built-in or wether it is one of several options. If the value is false, it can be assumed this exact item is built-in. If the value is true, it is unknown wether this or an alternative item is built-in.\nThis is the case when, e.g. the same item is supplied by two suppliers, the item is only tracked by a customer part ID during assembly. Thus, these items can not be differentiated from each other.\n\n"
},
"@id": "aspect:hasAlternatives",
"@type": "schema:boolean"
},
"id": "@id",
"lastModifiedOn": {
"@context": {
"@definition": "Timestamp when the assembly relationship between parent item and child item was last modified."
},
"@id": "aspect:lastModifiedOn",
"@type": "schema:string"
},
"quantity": {
"@context": {
"@definition": "Quantity of which the child item is assembled into the parent item. In general it is '1' for serialized parts.",
"@version": 1.1,
"id": "@id",
"type": "@type",
"unit": {
"@context": {
"@definition": "The unit of an item. Common units may be related to mass, count, linear, area, volume or misc."
},
"@id": "aspect:unit",
"@type": "schema:string"
},
"value": {
"@context": {
"@definition": "The quantity value associated with the unit."
},
"@id": "aspect:value",
"@type": "schema:number"
}
},
"@id": "aspect:quantity"
},
"type": "@type"
},
"@definition": "Set of child items, of which the given parent item was assembled by (one structural level down).",
"@version": 1.1,
"id": "@id",
"type": "@type"
},
"@id": "aspect:childItems"
},
"id": "@id",
"type": "@type"
},
"@id": "SingleLevelBomAsBuilt"
}
],
"type": [
"VerifiableCredential",
"CDC",
"DPP"
],
"issuer": "did:web:wallet-url.test.com:BPNL00000007RVTB",
"parent": {
"@id": "did:web:dpp-test-system.com:BPNL000000000000:api:public:urn%3Auuid%3A1c5b6a7c-90d4-3481-0538-f134ff53076d",
"checksum": "64b1a523da600e8fc0018cf57b8f7756b83bb6e9b11c81b1c7444272fab239902321b1b6ae6624d6846fd010616ae98c118f12491f922badd64e58b782c6a115"
},
"credentialSubject": {
"catenaXId": "urn:uuid:055c1128-0375-47c8-98de-7cf802c3241d",
"childItems": [
{
"catenaXId": "urn:uuid:055c1128-0375-47c8-98de-7cf802c3241d",
"quantity": {
"value": 20.0,
"unit": "unit:piece"
},
"hasAlternatives": false,
"createdOn": "2022-02-03T14:48:54.709Z",
"businessPartner": "BPNL50096894aNXY",
"lastModifiedOn": "2022-02-03T14:48:54.709Z"
}
]
},
"issuanceDate": "2024-02-15T00:00:00.000Z",
"proof": {
"type": "JsonWebSignature2020",
"created": "2024-02-15T12:35:39Z",
"verificationMethod": "did:web:wallet-url.test.com:BPNL00000007RVTB#8f858500-7008-4b97-a8bb-605d4c8eca75",
"proofPurpose": "assertionMethod",
"jws": "eyJhbGciOiJFZERTQSJ9..4snTkqta4UwXIAtKJiIEDhiwmVtAC3kml0j7Wc25vmTbLbPlviXgL9he9X0A0xRTNlnsEwILf0NbPIyeztzJCw"
}
}
Which can be expanded in this:
Hello @saudkhan116, @matbmoser
Since the feature is a 24.08 feature and the development phase is coming to an end, we need a status on the feature.
If you need any clarification, please get in touch, thank you very much. Stephan
Status here:
Signed for the first time the verifiable credential using a real private key:
I will try to verify it :)
We are also able to create the did endpoint for getting the public key with the method:
Content:
{
"id": "did:web:localhost%3A7777:BPNL00000000W3TR",
"verificationMethod": [
{
"publicKeyJwt": {
"kty": "OKP",
"kid": "d0963535-a285-4d34-8885-c50117fcbde5",
"crv": "Ed25519",
"x": "kz9ANMS6vEosKnL9LJJPJUG2Hdo7o37lE357aqvAdu0"
},
"controller": "did:web:localhost%3A7777:BPNL00000000W3TR",
"id": "did:web:localhost%3A7777:BPNL00000000W3TR#d0963535-a285-4d34-8885-c50117fcbde5",
"type": "JsonWebKey2020"
}
],
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3c.github.io/vc-jws-2020/contexts/v1"
]
}
For assuring data integrity I will add the checksum form the expanded json-ld in the signature:
I could finally verify our first credential issued!
Started working in migrating the simple wallet to tractus-x, it was before in my personal repository to test things: https://github.com/matbmoser/simple-wallet:
Working in the following branch https://github.com/eclipse-tractusx/digital-product-pass/tree/feature/simple-wallet
I just implemented authorization:
Now if the API key is not configured here:
The application will no accept the requests
For authentication requests the user needs to add its BPN:
BPN is like the "clientId" and the API Key the "clientSecret"
Ok I created a docker container for the wallet
I have registered the digital twin:
{
"description": [
{
"language": "en",
"text": "Battery Digital Twin"
}
],
"displayName": [],
"globalAssetId": "urn:uuid:a4c600e8-b11f-4e1d-a2f9-80ad518806b8",
"idShort": "Battery_DPP-XYZ789",
"id": "urn:uuid:a4c600e8-b11f-4e1d-a2f9-80ad518806b8",
"specificAssetIds":
[
{
"name": "digitalTwinType",
"value": "PartInstance",
"externalSubjectId": {
"type": "ExternalReference",
"keys": [
{
"type": "GlobalReference",
"value": "BPNL0073928UJ879"
}
]
}
},
{
"name": "partInstanceId",
"value": "DPPV-0001",
"externalSubjectId": {
"type": "ExternalReference",
"keys": [
{
"type": "GlobalReference",
"value": "BPNL0073928UJ879"
}
]
}
},
{
"name": "manufacturerPartId",
"value": "MPI7654",
"externalSubjectId": {
"type": "ExternalReference",
"keys": [
{
"type": "GlobalReference",
"value": "BPNL0073928UJ879"
},
{
"type": "GlobalReference",
"value": "PUBLIC_READABLE"
}
]
}
},
{
"name": "manufacturerId",
"value": "BPNL0073928UJ879",
"externalSubjectId": {
"type": "ExternalReference",
"keys": [
{
"type": "GlobalReference",
"value": "BPNL0073928UJ879"
}
]
}
}
],
"submodelDescriptors": [
{
"endpoints": [
{
"interface": "SUBMODEL-3.0",
"protocolInformation": {
"href": "https://dpp.int.demo.catena-x.net/BPNL000000000000/api/public/data/urn:uuid:a377ff49-6bde-4215-8d38-b8f02c991a35",
"endpointProtocol": "HTTP",
"endpointProtocolVersion": [
"1.1"
],
"subprotocol": "DSP",
"subprotocolBody": "id=urn:uuid:3e4a5957-f226-478a-ab18-79ced49d6195;dspEndpoint=https://dpp.int.demo.catena-x.net/BPNL000000000000",
"subprotocolBodyEncoding": "plain",
"securityAttributes": [
{
"type": "NONE",
"key": "NONE",
"value": "NONE"
}
]
}
}
],
"idShort": "digitalProductPass",
"id": "urn:uuid:a377ff49-6bde-4215-8d38-b8f02c991a35",
"semanticId": {
"type": "ExternalReference",
"keys": [
{
"type": "Entity",
"value": "https://www.w3.org/ns/credentials/v2"
},
{
"type": "DataElement",
"value": "urn:samm:io.catenax.dpp_verification.cdc:1.0.0#CertifiedDataCredential"
},
{
"type": "Submodel",
"value": "urn:samm:io.catenax.generic.digital_product_passport:4.0.0#DigitalProductPassport"
},
{
"type": "Operation",
"value": "https://w3c.github.io/vc-jws-2020/contexts/v1/"
}
]
},
"description": [
{
"language": "en",
"text": "Verifiable Digital Product Passport Submodel"
}
],
"displayName": []
}
]
}
In the submodel we included the following schema for the semantic Ids:
Ok the backend is finally able to verify the credentials:
I have configured a dpp consumer wallet and a dpp provider wallet so the provider can sign the credentials and the consumer another instance can verify the credential for the backend!
In case the Verifiable Credential is not able to be verified this is what we get:
Status here:
I could auto verify and retrieve the data from the backend!
I present the first verifiable credential which is working, verified E2E and presented in the frontend !
All the PRs are create and waiting to be reviewed and merged!
Final PoC is implemented and working:
Included in a DPP release v4.0.0
Ok, Issue Documentation updated to match developments and artifacts produced. I also added the issue ticket for the documentation which is still open. I am updating the documentation to match the implementation.
@stephanbcbauer updated the description of this feature and detailed all the aspects like dependecies etc...
Latest Version Will be published in this PR digital-product-pass#388
Description
The Digital Product Pass Verification is a work in progress add-on that is being done at the end of consortia phase. The documentation was published in the release R24.05 https://github.com/eclipse-tractusx/digital-product-pass/blob/main/dpp-verification and it explains how the concept is.
This implementation is limited to the "consumer" part and enables the Minimal Viable Solution for "certifying" data and testing its verification in the Digital Product Pass application. Since the DPP application is only a consumer application.
Objectives
simple-wallet
that uses an Gaia-X compliant signature type and replicates the most simple functionality of the managed-identity-wallet, for issuing verifiable credentials and verifying the credentials. Enabling any Catena-X Semantic Model modeled in Samm to be issued as a JSON-LD Verifiable Credential v2.dpp-backend
anddpp-frontend
components for verifying data incoming from an EDC using thesimple-wallet
component.dpp-frontend
to display information and results about the verification status of the data visualized.Context Diagram
User Changelog
Digital Product Pass Verification Add-on Backend Implementation
Digital Product Pass Verification Add-on Implementation is finally available at the digital product pass backend. The backend was refactored to be constructure in a modular way. All the core components of the backend were moved into the 'core' module. The 'verification' module includes all the functionality required to verify credentials using the simple wallet component.
Digital Product Pass Simple Wallet from DPP Verification Add-on Available
A functional wallet developed in Python is now available. It is a minimal viable wallet component that can be used to:
Digital Product Pass Verification Add-on Schemas and Semantics Available
Now the semantic models for the Certified Data Credential and some examples are available under dpp-verification semantics. Also its available the json-ld schemas for the digital product pass aspect model and the certified data credential under schemas.
Digital Product Pass Verification Add-on Frontend Implementation
Visualize if the credential you are retriving is verifiable or not. Be able to refresh the verification of the credential signature on the fly and be able to visualize the issuer, owner and wallet that handled the verification.
Impact
Dependencies
Additional information
Link to documentation: https://github.com/eclipse-tractusx/digital-product-pass/tree/main/dpp-verification
Tasks
Committers
Pull Requests
Related Issues
Artifacts