-
Notifications
You must be signed in to change notification settings - Fork 14
Description
What is missing?
Actually AAS data does not provide signed content.
This is needed for end to end value chains to prove that AAS data was not accidentally or intentionally changed.
An example of such value chain is: device manufacturer supplies to integrator and integrator supplies to plant operator. In case of an accident in the plant it must be possible for the plant operator to check that he had used the original non changed data of the device manufacturer.
Some companies (see also DDCC Digital Data Chain Consortium) also copy AAS data for long term availability.
How should it be fixed?
A first basic step will be to provide a signed identifiable, i.e. signed aas, submodel or concept description.
The format of the signature has been discussed in the TF Security. Several related POCs have been built with alternatives by AAS submodel, JWS (Jason Web Signature) or even JAdES (JSON Advanced Electronic Signature).
It has been decided that for a first basic step the internationally well established JWS shall be used with embedded content of identiable as JSON.
For each identifiable an additional endpoint /$signed shall be added (similar to /$value).
$signed shall simply return string as result which is the JWS.
The specific content of the JWS string will be explained in the Part 4 Security specification.
A POC with AASPE Server is available. An example of a related JWS can be seen here:
https://big.aas-voyager.com/submodels/aHR0cHM6Ly9pNGQuZGUvVC8wODI2ODQwL3N1Ym1vZGVsL1RlY2huaWNhbERhdGE/$sign
This may be decoded by jwt.io. Since only standard elements have been used, jwt.io can even prove the signature automatically by the x5c in JWS.
- I have signed the required Developer Certificate of Origin (DCO) already.