From 50a86b7a7d767a03512a4567d79d3c39cabbf333 Mon Sep 17 00:00:00 2001 From: pcnorth Date: Wed, 27 Mar 2024 14:57:10 +0000 Subject: [PATCH] deploy: a5b7529af8d60745620d63496a97c464e659553a --- 404.html | 2 +- contributors/index.html | 2 +- .../app-registrations-api/index.html | 2 +- .../api-reference/assets-api/index.html | 2 +- .../api-reference/attachments-api/index.html | 2 +- developers/api-reference/blobs-api/index.html | 2 +- .../api-reference/blockchain-api/index.html | 2 +- developers/api-reference/caps-api/index.html | 2 +- .../api-reference/compliance-api/index.html | 2 +- .../api-reference/events-api/index.html | 2 +- .../api-reference/iam-policies-api/index.html | 2 +- .../api-reference/iam-subjects-api/index.html | 2 +- developers/api-reference/index.html | 2 +- .../api-reference/locations-api/index.html | 2 +- .../public-assets-api/index.html | 2 +- .../api-reference/system-api/index.html | 2 +- .../api-reference/tenancies-api/index.html | 2 +- .../containers-as-assets/index.html | 2 +- .../document-profile/index.html | 2 +- .../index.html | 2 +- developers/developer-patterns/index.html | 2 +- .../developer-patterns/namespace/index.html | 2 +- .../developer-patterns/scitt-api/index.html | 2 +- .../software-package-profile/index.html | 2 +- .../verifying-with-simple-hash/index.html | 2 +- developers/index.html | 2 +- developers/yaml-reference/assets/index.html | 2 +- .../yaml-reference/compliance/index.html | 2 +- .../yaml-reference/estate-info/index.html | 2 +- developers/yaml-reference/events/index.html | 2 +- developers/yaml-reference/index.html | 2 +- .../yaml-reference/locations/index.html | 2 +- .../story-runner-components/index.html | 2 +- developers/yaml-reference/subjects/index.html | 2 +- glossary/common-datatrails-terms/index.html | 2 +- glossary/index.html | 2 +- glossary/reserved-attributes/index.html | 2 +- index.html | 2 +- ...81349d5f71a8f541ac4f6cc6bd4494582ef0f9d.js | 112 ++++++++++-------- .../compliance-policies/index.html | 2 +- .../dropbox-integration/index.html | 2 +- .../grouping-assets-by-location/index.html | 2 +- .../identity-and-access-management/index.html | 2 +- platform/administration/index.html | 2 +- .../index.html | 2 +- .../index.html | 2 +- .../administration/verified-domain/index.html | 2 +- platform/index.html | 2 +- .../overview/advanced-concepts/index.html | 29 ++--- platform/overview/core-concepts/index.html | 2 +- .../overview/creating-an-asset/index.html | 2 +- .../index.html | 2 +- platform/overview/index.html | 2 +- platform/overview/index.xml | 6 +- platform/overview/instaproof/index.html | 2 +- platform/overview/introduction/index.html | 2 +- .../overview/public-attestation/index.html | 2 +- .../index.html | 2 +- .../index.html | 2 +- platform/overview/sitemap.xml | 2 +- platform/sitemap.xml | 2 +- sales/contactus/index.html | 2 +- sales/index.html | 2 +- sitemap.xml | 2 +- support/contactus/index.html | 2 +- support/index.html | 2 +- .../authenticity-and-attestation/index.html | 2 +- usecases/bill-of-materials/index.html | 2 +- usecases/index.html | 2 +- usecases/state-machine/index.html | 2 +- 70 files changed, 149 insertions(+), 132 deletions(-) rename index.min.ebf5c7d2301df869846c3757d5663662b88cbb785c50fff280a96a20de115aa5c994fb502e67eb8b3851b56d2bde059b349566ded6e10fce615cb67cbbf4d0f2.js => index.min.f2a0b4d14203872f118ad434044411eba08754978e87a468a4f65ff2d6845ea89f532a5dafdd10af1f88145af81349d5f71a8f541ac4f6cc6bd4494582ef0f9d.js (99%) diff --git a/404.html b/404.html index b21f3cf85..c73f30753 100644 --- a/404.html +++ b/404.html @@ -5,4 +5,4 @@
\ No newline at end of file +Sign Up
\ No newline at end of file diff --git a/contributors/index.html b/contributors/index.html index 40397ba8a..25bc77539 100644 --- a/contributors/index.html +++ b/contributors/index.html @@ -5,4 +5,4 @@

Contributors

\ No newline at end of file +Sign Up

Contributors

\ No newline at end of file diff --git a/developers/api-reference/app-registrations-api/index.html b/developers/api-reference/app-registrations-api/index.html index fb6c9c15a..5a363d3e1 100644 --- a/developers/api-reference/app-registrations-api/index.html +++ b/developers/api-reference/app-registrations-api/index.html @@ -201,4 +201,4 @@ "display_name": "test", "identity": "applications/ffaa0f30-a503-4de7-b085-d857ed34a7cd", "tenant_id": "tenant/fafb2d41-5237-45c7-9740-66d1635f549b" -}
Response ParameterTypeDescription
client_idstringClient ID for use in OIDC client credentials flow
credentialsarrayDescribes a single time-limited secret
custom_claimsobjectCustom claims to add to Application for use in access policies.
display_namestringHuman-readable display name for this Application.
identitystringResource name for the application
tenant_idstringIdentity of the tenant owning this application
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized.
404Returned when the Application does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Software Package Profile
Assets API →
\ No newline at end of file +}
Response ParameterTypeDescription
client_idstringClient ID for use in OIDC client credentials flow
credentialsarrayDescribes a single time-limited secret
custom_claimsobjectCustom claims to add to Application for use in access policies.
display_namestringHuman-readable display name for this Application.
identitystringResource name for the application
tenant_idstringIdentity of the tenant owning this application
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized.
404Returned when the Application does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Software Package Profile
Assets API →
\ No newline at end of file diff --git a/developers/api-reference/assets-api/index.html b/developers/api-reference/assets-api/index.html index 738265c71..7edeb861a 100644 --- a/developers/api-reference/assets-api/index.html +++ b/developers/api-reference/assets-api/index.html @@ -449,4 +449,4 @@ }
Response ParameterTypeDescription
asset_attributesobjectkey value mapping of asset attributes
asset_identitystringidentity of a related asset resource assets/11bf5b37-e0b8-42e0-8dcf-dc8c4aefc000
behaviourstringThe behaviour used to create event. RecordEvidence
block_numberstringnumber of block event was commited on
confirmation_statusstringindicates if the event has been succesfully committed to the blockchain
event_attributesobjectkey value mapping of event attributes
fromstringwallet address for the creator of this event
identitystringidentity of a event resource
merklelog_entryobjectverifiable merkle mmr log entry details
operationstringThe operation represented by the event. Record
principal_acceptedobjectprincipal recorded by the server
principal_declaredobjectprincipal provided by the user
tenant_identitystringIdentity of the tenant the that created this event
timestamp_acceptedstringtime of event as recorded by the server
timestamp_committedstringtime of event as recorded in verifiable storage
timestamp_declaredstringtime of event as declared by the user
transaction_idstringhash of the transaction as a hex string 0x11bf5b37e0b842e08dcfdc8c4aefc000
transaction_indexstringindex of event within commited block
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
402Returned when the user’s quota of Events has been reached.
429Returned when a user exceeds their subscription’s rate limit for requests.

get  /archivist/v2/assets/archivist/v2/assets/{uuid}:publicurl

Retrieves the Asset public url

Description: Retrieves the public url for a specific Asset.

{
   "publicurl": "https://app.datatrails.ai/archivist/publicassets/add30235-1424-4fda-840a-d5ef82c4c96f"
-}
Response ParameterTypeDescription
publicurlstring
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to view an Asset.
404Returned when the asset with the id does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← App Registrations API
Attachments API →
\ No newline at end of file +}
Response ParameterTypeDescription
publicurlstring
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to view an Asset.
404Returned when the asset with the id does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← App Registrations API
Attachments API →
\ No newline at end of file diff --git a/developers/api-reference/attachments-api/index.html b/developers/api-reference/attachments-api/index.html index 525774f2e..1b66664c4 100644 --- a/developers/api-reference/attachments-api/index.html +++ b/developers/api-reference/attachments-api/index.html @@ -103,4 +103,4 @@ "subject": "user-xxxx@example.com", "tenantid": "tenant/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "timestamp_accepted": "2019-11-07T15:31:49Z" -}
Response ParameterTypeDescription
hashblob hash.
identitystringblob identity.
issuerstringprincipal issuer.
mime_typestringhttp mime type.
scanned_bad_reasonstringif scanned as SCANNED_BAD contains a hint of scan result.
scanned_statusstringstatus of scan.
scanned_timestampstringdate and time when the attachments has been scanned.
sizeintegersize of the blob.
subjectstringprincipal subject.
tenantidstringidentity of the tenant the blob belongs to.
timestamp_acceptedstringdate and time when the request has been received.
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
404Returned when the underlying system can’t find the asset.

← Assets API
Blobs API →
\ No newline at end of file +}
Response ParameterTypeDescription
hashblob hash.
identitystringblob identity.
issuerstringprincipal issuer.
mime_typestringhttp mime type.
scanned_bad_reasonstringif scanned as SCANNED_BAD contains a hint of scan result.
scanned_statusstringstatus of scan.
scanned_timestampstringdate and time when the attachments has been scanned.
sizeintegersize of the blob.
subjectstringprincipal subject.
tenantidstringidentity of the tenant the blob belongs to.
timestamp_acceptedstringdate and time when the request has been received.
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
404Returned when the underlying system can’t find the asset.

← Assets API
Blobs API →
\ No newline at end of file diff --git a/developers/api-reference/blobs-api/index.html b/developers/api-reference/blobs-api/index.html index bc8445d1d..4f4ca6f74 100644 --- a/developers/api-reference/blobs-api/index.html +++ b/developers/api-reference/blobs-api/index.html @@ -87,4 +87,4 @@ "subject": "user-xxxx@example.com", "tenantid": "tenant/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "timestamp_accepted": "2019-11-07T15:31:49Z" -}
Response ParameterTypeDescription
hashblob hash.
identitystringblob identity.
issuerstringprincipal issuer.
mime_typestringhttp mime type.
scanned_bad_reasonstringif scanned as SCANNED_BAD contains a hint of scan result.
scanned_statusstringstatus of scan.
scanned_timestampstringdate and time when the attachments has been scanned.
sizeintegersize of the blob.
subjectstringprincipal subject.
tenantidstringidentity of the tenant the blob belongs to.
timestamp_acceptedstringdate and time when the request has been received.
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to get the blob metadata.
429Returned when a user exceeds their subscription’s rate limit for requests.
500Returned when the underlying system returns an error.

← Attachments API
Blockchain API (v1alpha2) →
\ No newline at end of file +}
Response ParameterTypeDescription
hashblob hash.
identitystringblob identity.
issuerstringprincipal issuer.
mime_typestringhttp mime type.
scanned_bad_reasonstringif scanned as SCANNED_BAD contains a hint of scan result.
scanned_statusstringstatus of scan.
scanned_timestampstringdate and time when the attachments has been scanned.
sizeintegersize of the blob.
subjectstringprincipal subject.
tenantidstringidentity of the tenant the blob belongs to.
timestamp_acceptedstringdate and time when the request has been received.
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to get the blob metadata.
429Returned when a user exceeds their subscription’s rate limit for requests.
500Returned when the underlying system returns an error.

← Attachments API
Blockchain API (v1alpha2) →
\ No newline at end of file diff --git a/developers/api-reference/blockchain-api/index.html b/developers/api-reference/blockchain-api/index.html index b3b326d35..d26e5aeee 100644 --- a/developers/api-reference/blockchain-api/index.html +++ b/developers/api-reference/blockchain-api/index.html @@ -85,4 +85,4 @@ } } ] -}
Response ParameterTypeDescription
next_page_tokenstringToken to retrieve the next page of results or empty if there are none.
transactionsarray
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to view event’s blockchain transactions.
404Returned when the asset with the id does not exist. or the event with the id does not exist
429Returned when a user exceeds their subscription’s rate limit for requests.

← Blobs API
Compliance API →
\ No newline at end of file +}
Response ParameterTypeDescription
next_page_tokenstringToken to retrieve the next page of results or empty if there are none.
transactionsarray
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to view event’s blockchain transactions.
404Returned when the asset with the id does not exist. or the event with the id does not exist
429Returned when a user exceeds their subscription’s rate limit for requests.

← Blobs API
Compliance API →
\ No newline at end of file diff --git a/developers/api-reference/caps-api/index.html b/developers/api-reference/caps-api/index.html index 95628af1c..a764d59c1 100644 --- a/developers/api-reference/caps-api/index.html +++ b/developers/api-reference/caps-api/index.html @@ -24,4 +24,4 @@ } ] } -

These are the available values for “?service=”:

Caps OpenAPI Docs

API providing caps data for DataTrails APIs

get  /archivist/v1/caps/archivist/v1/caps

Returns caps for the given resource

Description: Returns caps for the given resource

ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to access the resource.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Estate Information YAML Runner
\ No newline at end of file +

These are the available values for “?service=”:

Caps OpenAPI Docs

API providing caps data for DataTrails APIs

get  /archivist/v1/caps/archivist/v1/caps

Returns caps for the given resource

Description: Returns caps for the given resource

ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to access the resource.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Estate Information YAML Runner
\ No newline at end of file diff --git a/developers/api-reference/compliance-api/index.html b/developers/api-reference/compliance-api/index.html index 0f31cc4d4..1e59c33fa 100644 --- a/developers/api-reference/compliance-api/index.html +++ b/developers/api-reference/compliance-api/index.html @@ -193,4 +193,4 @@ "event_display_type": "Maintenance Performed", "identity": "compliance_policies/463fab3a-bae5-4349-8f76-f6454da20c9d", "time_period_seconds": 86800 -}
Response ParameterTypeDescription
asset_filterarrayFilter
closing_event_display_typestring
compliance_type
descriptionstring
display_namestring
dynamic_variabilitynumber
dynamic_windowstring
event_display_typestring
identitystring
richness_assertionsarrayFilter
time_period_secondsstring
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to access the requested resource.
404Returned when the asset with the id does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Blockchain API (v1alpha2)
Events API →
\ No newline at end of file +}
Response ParameterTypeDescription
asset_filterarrayFilter
closing_event_display_typestring
compliance_type
descriptionstring
display_namestring
dynamic_variabilitynumber
dynamic_windowstring
event_display_typestring
identitystring
richness_assertionsarrayFilter
time_period_secondsstring
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to access the requested resource.
404Returned when the asset with the id does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Blockchain API (v1alpha2)
Events API →
\ No newline at end of file diff --git a/developers/api-reference/events-api/index.html b/developers/api-reference/events-api/index.html index 173d526b6..2f60edebd 100644 --- a/developers/api-reference/events-api/index.html +++ b/developers/api-reference/events-api/index.html @@ -534,4 +534,4 @@ }
Response ParameterTypeDescription
asset_attributesobjectkey value mapping of asset attributes
asset_identitystringidentity of a related asset resource assets/11bf5b37-e0b8-42e0-8dcf-dc8c4aefc000
behaviourstringThe behaviour used to create event. RecordEvidence
block_numberstringnumber of block event was commited on
confirmation_statusstringindicates if the event has been succesfully committed to the blockchain
event_attributesobjectkey value mapping of event attributes
fromstringwallet address for the creator of this event
identitystringidentity of a event resource
merklelog_entryobjectverifiable merkle mmr log entry details
operationstringThe operation represented by the event. Record
principal_acceptedobjectprincipal recorded by the server
principal_declaredobjectprincipal provided by the user
tenant_identitystringIdentity of the tenant the that created this event
timestamp_acceptedstringtime of event as recorded by the server
timestamp_committedstringtime of event as recorded in verifiable storage
timestamp_declaredstringtime of event as declared by the user
transaction_idstringhash of the transaction as a hex string 0x11bf5b37e0b842e08dcfdc8c4aefc000
transaction_indexstringindex of event within commited block
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
402Returned when the user’s quota of Events has been reached.
429Returned when a user exceeds their subscription’s rate limit for requests.

get  /archivist/v2/assets/archivist/v2/assets/{uuid}:publicurl

Retrieves the Asset public url

Description: Retrieves the public url for a specific Asset.

{
   "publicurl": "https://app.datatrails.ai/archivist/publicassets/add30235-1424-4fda-840a-d5ef82c4c96f"
-}
Response ParameterTypeDescription
publicurlstring
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to view an Asset.
404Returned when the asset with the id does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Compliance API
IAM Policies API →
\ No newline at end of file +}
Response ParameterTypeDescription
publicurlstring
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to view an Asset.
404Returned when the asset with the id does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Compliance API
IAM Policies API →
\ No newline at end of file diff --git a/developers/api-reference/iam-policies-api/index.html b/developers/api-reference/iam-policies-api/index.html index f90e86f3c..fae500f02 100644 --- a/developers/api-reference/iam-policies-api/index.html +++ b/developers/api-reference/iam-policies-api/index.html @@ -636,4 +636,4 @@ } ], "page_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6InN0dW50aWR" -}
Response ParameterTypeDescription
access_policiesarrayDescribes an Access Policy for OBAC
next_page_tokenstringToken to retrieve the next page of results or empty if there are none.
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to list the access policy.
404Returned when the identified access policy does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.
500Returned when the underlying storage system returns an error.

← Events API
IAM Subjects API →
\ No newline at end of file +}
Response ParameterTypeDescription
access_policiesarrayDescribes an Access Policy for OBAC
next_page_tokenstringToken to retrieve the next page of results or empty if there are none.
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to list the access policy.
404Returned when the identified access policy does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.
500Returned when the underlying storage system returns an error.

← Events API
IAM Subjects API →
\ No newline at end of file diff --git a/developers/api-reference/iam-subjects-api/index.html b/developers/api-reference/iam-subjects-api/index.html index c89d20fae..bd3166ed8 100644 --- a/developers/api-reference/iam-subjects-api/index.html +++ b/developers/api-reference/iam-subjects-api/index.html @@ -160,4 +160,4 @@ "wallet_pub_key": [ "key1" ] -}
Response ParameterTypeDescription
confirmation_status
display_namestringCustomer friendly name for the subject.
identitystringUnique identification for the subject, Relative Resource Name
tenantstringTenent id
tessera_pub_keyarrayOrganisation’s tessara wallet keys (BNF)
wallet_addressarrayOrganisation’s wallet addresses
wallet_pub_keyarrayOrganisation’s public wallet keys (BNF)
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to update the subject.
404Returned when the identified subject does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.
500Returned when the underlying storage system returns an error.

← IAM Policies API
Quickstart: SCITT Statements (Preview) →
\ No newline at end of file +}
Response ParameterTypeDescription
confirmation_status
display_namestringCustomer friendly name for the subject.
identitystringUnique identification for the subject, Relative Resource Name
tenantstringTenent id
tessera_pub_keyarrayOrganisation’s tessara wallet keys (BNF)
wallet_addressarrayOrganisation’s wallet addresses
wallet_pub_keyarrayOrganisation’s public wallet keys (BNF)
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to update the subject.
404Returned when the identified subject does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.
500Returned when the underlying storage system returns an error.

← IAM Policies API
Quickstart: SCITT Statements (Preview) →
\ No newline at end of file diff --git a/developers/api-reference/index.html b/developers/api-reference/index.html index d6808e1eb..97996889c 100644 --- a/developers/api-reference/index.html +++ b/developers/api-reference/index.html @@ -5,4 +5,4 @@
\ No newline at end of file +Sign Up
\ No newline at end of file diff --git a/developers/api-reference/locations-api/index.html b/developers/api-reference/locations-api/index.html index 78fefa7c5..186020e12 100644 --- a/developers/api-reference/locations-api/index.html +++ b/developers/api-reference/locations-api/index.html @@ -180,4 +180,4 @@ "orgb" ] } -}
Response ParameterTypeDescription
location_identitystringThe location identity in the form: locations/{uuid}
permissionsSubject identities this location is shared with
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to access permissions for the location.
404Returned when the identified location does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Quickstart: SCITT Statements (Preview)
Public Assets API →
\ No newline at end of file +}
Response ParameterTypeDescription
location_identitystringThe location identity in the form: locations/{uuid}
permissionsSubject identities this location is shared with
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to access permissions for the location.
404Returned when the identified location does not exist.
429Returned when a user exceeds their subscription’s rate limit for requests.

← Quickstart: SCITT Statements (Preview)
Public Assets API →
\ No newline at end of file diff --git a/developers/api-reference/public-assets-api/index.html b/developers/api-reference/public-assets-api/index.html index eb8eb523f..b0c6f2022 100644 --- a/developers/api-reference/public-assets-api/index.html +++ b/developers/api-reference/public-assets-api/index.html @@ -275,4 +275,4 @@ } ], "next_page_token": "abcd" -}
Response ParameterTypeDescription
eventsarrayThis describes an Event.
next_page_tokenstringToken to retrieve the next page of results or empty if there are none.
ResponsesDescription
200A successful response.
206The number of events exceeds the servers limit. The approximate number of matching results is provided by the x-total-count header, the exact limit is available in the content-range header. The value format is ‘items 0-LIMIT/TOTAL’. Note that x-total-count is always present for 200 and 206 responses. It is the servers best available approximation. Similarly, in any result set, you may get a few more than LIMIT items.

← Locations API
System API →
\ No newline at end of file +}
Response ParameterTypeDescription
eventsarrayThis describes an Event.
next_page_tokenstringToken to retrieve the next page of results or empty if there are none.
ResponsesDescription
200A successful response.
206The number of events exceeds the servers limit. The approximate number of matching results is provided by the x-total-count header, the exact limit is available in the content-range header. The value format is ‘items 0-LIMIT/TOTAL’. Note that x-total-count is always present for 200 and 206 responses. It is the servers best available approximation. Similarly, in any result set, you may get a few more than LIMIT items.

← Locations API
System API →
\ No newline at end of file diff --git a/developers/api-reference/system-api/index.html b/developers/api-reference/system-api/index.html index 1c29aa07b..af20af37b 100644 --- a/developers/api-reference/system-api/index.html +++ b/developers/api-reference/system-api/index.html @@ -120,4 +120,4 @@ "stateRoot": "0xb1bf30baaed044489b769f4bc557594f74e917b297b79ebe88102a856490cfc4", "timestamp": "0xf426", "transactionRoot": "0x5d912ec4fd96825fc58e75401d9834e94bf2fd8f01e50d6946831a60ec1c2040" -}
Response ParameterTypeDescription
difficultystringinteger of the difficulty for this block encoded as a hexadecimal
extraDatastringthe “extra data” field of this block
gasLimitstringthe maximum gas allowed in this block encoded as a hexadecimal
gasUsedstringthe total used gas by all transactions in this block encoded as a hexadecimal
hashstringthe block hash
logsBloomstringthe bloom filter for the logs of the block
minerstringthe address of the beneficiary to whom the mining rewards were given
noncestringhash of the generated proof of work
numberstringthe block number in hexidecimal
parentHashstringhash of the parent block
privateStateRootstringthe root of the final, node specific, private state trie of the block
receiptsRootstringthe root of the receipts trie of the block
sha3Unclesstringsha3 hash of the uncles data in the block
stateRootstringthe root of the final state trie of the block
timestampstringthe unix timestamp for when the block was collated
transactionRootstringthe root of the transaction trie of the block
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to view the block.
404Returned when the asset with the id does not exist. or the event with the id does not exist
429Returned when a user exceeds their subscription’s rate limit for requests.

← Public Assets API
Tenancies API →
\ No newline at end of file +}
Response ParameterTypeDescription
difficultystringinteger of the difficulty for this block encoded as a hexadecimal
extraDatastringthe “extra data” field of this block
gasLimitstringthe maximum gas allowed in this block encoded as a hexadecimal
gasUsedstringthe total used gas by all transactions in this block encoded as a hexadecimal
hashstringthe block hash
logsBloomstringthe bloom filter for the logs of the block
minerstringthe address of the beneficiary to whom the mining rewards were given
noncestringhash of the generated proof of work
numberstringthe block number in hexidecimal
parentHashstringhash of the parent block
privateStateRootstringthe root of the final, node specific, private state trie of the block
receiptsRootstringthe root of the receipts trie of the block
sha3Unclesstringsha3 hash of the uncles data in the block
stateRootstringthe root of the final state trie of the block
timestampstringthe unix timestamp for when the block was collated
transactionRootstringthe root of the transaction trie of the block
ResponsesDescription
200A successful response.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to view the block.
404Returned when the asset with the id does not exist. or the event with the id does not exist
429Returned when a user exceeds their subscription’s rate limit for requests.

← Public Assets API
Tenancies API →
\ No newline at end of file diff --git a/developers/api-reference/tenancies-api/index.html b/developers/api-reference/tenancies-api/index.html index fcd34afe1..74e2486eb 100644 --- a/developers/api-reference/tenancies-api/index.html +++ b/developers/api-reference/tenancies-api/index.html @@ -114,4 +114,4 @@ "identity": "tenant/12149552-f258-430d-922b-4bcd8413ee30" } ] -}
Response ParameterTypeDescription
next_page_tokenstringToken to retrieve the next page of results or empty if there are none.
tenantsarrayTenant information for a user.
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to read the user.
404Returned when the identified user don’t exist.
500Returned when the underlying storage system returns an error.

← System API
YAML Runner Components →
\ No newline at end of file +}
Response ParameterTypeDescription
next_page_tokenstringToken to retrieve the next page of results or empty if there are none.
tenantsarrayTenant information for a user.
ResponsesDescription
200A successful response.
400Returned when the request is badly formed.
401Returned when the user is not authenticated to the system.
403Returned when the user is not authorized to read the user.
404Returned when the identified user don’t exist.
500Returned when the underlying storage system returns an error.

← System API
YAML Runner Components →
\ No newline at end of file diff --git a/developers/developer-patterns/containers-as-assets/index.html b/developers/developer-patterns/containers-as-assets/index.html index 68c3fbcea..25e8ad2e5 100644 --- a/developers/developer-patterns/containers-as-assets/index.html +++ b/developers/developer-patterns/containers-as-assets/index.html @@ -102,4 +102,4 @@ 
curl -g -X GET \
      -H "$HOME/.datatrails/bearer-token.txt" \
      "https://app.datatrails.ai/archivist/v2/assets?attributes.within_container=Shipping%20Container" | jq
-

← Creating Access Tokens Using a Custom Integration
Namespace →
\ No newline at end of file +

← Creating Access Tokens Using a Custom Integration
Namespace →
\ No newline at end of file diff --git a/developers/developer-patterns/document-profile/index.html b/developers/developer-patterns/document-profile/index.html index c405a8555..8c35ebc49 100644 --- a/developers/developer-patterns/document-profile/index.html +++ b/developers/developer-patterns/document-profile/index.html @@ -16,4 +16,4 @@ } ]
Asset AttributesMeaningRequirement
document_hash_valueHash of this version of the documentRequired
document_hash_algAlgorithm used for hashing. We only officially support SHA-256.Required
document_statusLabel for filtering and accommodating critical document lifecycle eventsRequired, must be Published
document_documentAttachment containing this version of the documentOptional
document_versionVersion string for the this version of the documentOptional

Withdraw Event

If a document is no longer required, or if for any reason it is decided that it should no longer be used, then a document can be withdrawn. -Withdrawal is optional and it is usually the final event in the document lifecycle. It can be reversed in DataTrails by publishing a new version.

Withdraw an entire document (mark that it is no longer considered current.)

Event AttributesMeaningRequirement
arc_display_typeTells DataTrails how to interpret EventRequired, must be set to Withdraw
document_withdrawal_reasonReason why document has been withdrawnOptional, but encouraged
Asset AttributesMeaningRequirement
document_statusLabel for filtering and accommodating critical document lifecycle eventsRequired, must be Withdrawn

← Verifying Assets and Events with Simple Hash
Software Package Profile →
\ No newline at end of file +Withdrawal is optional and it is usually the final event in the document lifecycle. It can be reversed in DataTrails by publishing a new version.

Withdraw an entire document (mark that it is no longer considered current.)

Event AttributesMeaningRequirement
arc_display_typeTells DataTrails how to interpret EventRequired, must be set to Withdraw
document_withdrawal_reasonReason why document has been withdrawnOptional, but encouraged
Asset AttributesMeaningRequirement
document_statusLabel for filtering and accommodating critical document lifecycle eventsRequired, must be Withdrawn

← Verifying Assets and Events with Simple Hash
Software Package Profile →
\ No newline at end of file diff --git a/developers/developer-patterns/getting-access-tokens-using-app-registrations/index.html b/developers/developer-patterns/getting-access-tokens-using-app-registrations/index.html index 239ab0c0a..6a57b5605 100644 --- a/developers/developer-patterns/getting-access-tokens-using-app-registrations/index.html +++ b/developers/developer-patterns/getting-access-tokens-using-app-registrations/index.html @@ -88,4 +88,4 @@ "iss": "https://app.datatrails.ai/appidpv1", "aud": "https://app.datatrails.ai/archivist" } -

Containers as Assets →
\ No newline at end of file +

Containers as Assets →
\ No newline at end of file diff --git a/developers/developer-patterns/index.html b/developers/developer-patterns/index.html index b4521299f..798ef8904 100644 --- a/developers/developer-patterns/index.html +++ b/developers/developer-patterns/index.html @@ -5,4 +5,4 @@

Developer Patterns

This sub-section of the Developers subject area contains more detailed information on topics that cannot be covered by the API or YAML Runner references.

You will find articles on common developer tasks and concept guides that are relevant to developers.

Check out the articles below for more information!


Getting Access Tokens using App Registrations →
Containers as Assets →
Namespace →
Verifying Assets and Events with Simple Hash →
Document Profile →
Software Package Profile →

\ No newline at end of file +Sign Up

Developer Patterns

This sub-section of the Developers subject area contains more detailed information on topics that cannot be covered by the API or YAML Runner references.

You will find articles on common developer tasks and concept guides that are relevant to developers.

Check out the articles below for more information!


Getting Access Tokens using App Registrations →
Containers as Assets →
Namespace →
Verifying Assets and Events with Simple Hash →
Document Profile →
Software Package Profile →

\ No newline at end of file diff --git a/developers/developer-patterns/namespace/index.html b/developers/developer-patterns/namespace/index.html index e7e3f0e10..f27ba393c 100644 --- a/developers/developer-patterns/namespace/index.html +++ b/developers/developer-patterns/namespace/index.html @@ -22,4 +22,4 @@ }

To use namespace as a variable, such as the date, add the argument to your Bash environment:

 export TEST_NAMESPACE=date

See -TEST_NAMESPACE in our GitHub repository for more information. TEST_NAMESPACE can also be added to your Bash profile to be automatically picked up when testing.

← Containers as Assets
Verifying Assets and Events with Simple Hash →
\ No newline at end of file +TEST_NAMESPACE in our GitHub repository for more information. TEST_NAMESPACE can also be added to your Bash profile to be automatically picked up when testing.

← Containers as Assets
Verifying Assets and Events with Simple Hash →
\ No newline at end of file diff --git a/developers/developer-patterns/scitt-api/index.html b/developers/developer-patterns/scitt-api/index.html index e3caf8212..476945a02 100644 --- a/developers/developer-patterns/scitt-api/index.html +++ b/developers/developer-patterns/scitt-api/index.html @@ -62,4 +62,4 @@
Coming soon: Filter on specific content types, such as what SBOMs have been registered, or which issuers have made statements.

Summary

The quickstart created a collection of statements for a given artifact. Over time, as new information is available, authors can publish new statements which verifiers and consumers can benefit from. There are no limits to the types of additional statements that may be registered, which may include new vulnerability information, notifications of new versions, end of life (EOL) notifications, or more. -By using the content-type parameter, verifiers can filter to specific types, and/or filter statements by the issuer.

For more information:

← IAM Subjects API
Locations API →
\ No newline at end of file +By using the content-type parameter, verifiers can filter to specific types, and/or filter statements by the issuer.

For more information:

← IAM Subjects API
Locations API →
\ No newline at end of file diff --git a/developers/developer-patterns/software-package-profile/index.html b/developers/developer-patterns/software-package-profile/index.html index 10bf0db70..46b10b5de 100644 --- a/developers/developer-patterns/software-package-profile/index.html +++ b/developers/developer-patterns/software-package-profile/index.html @@ -44,4 +44,4 @@ "public": true }

Software Package Profile Event Types and Attributes

Release Event

A Release is the event used by a Supplier to provide an SBOM for their Software Package in DataTrails.

The Release attributes tracked in DataTrails should minimally represent the base information required by the NTIA standard and be recorded in two, separate, lists of attributes; Asset Attributes would track details about the latest release of the SBOM at the time of the event creation, the Event Attributes then track details about the release of the SBOM that is being submitted.

Release Event Attribute Namespace

The sbom_ prefix is used to designate attributes that are part of the event and asset. Some of these are interpreted by DataTrails and others are guidelines

NTIA AttributeEvent AttributesMeaningRequirement
N/Aarc_display_typeTells DataTrails how to interpret EventRequired, must set to Release
Author Namesbom_authorThe name of the Package AuthorRequired
Supplier Namesbom_supplierThe name of the Package AuthorRequired
Component Namesbom_componentThe name of the PackageRequired
Version Stringsbom_versionThe version of the PackageRequired
Unique Identifiersbom_uuidA unique identifier for the Package, DataTrails provides a Unique ID per asset but it may be preferred to include an existing internal reference insteadRequired
N/Asbom_repoLink to the Git Repo of the ComponentOptional
N/Asbom_release_notesLink to the release notes of the releaseOptional
N/Asbom_licenseThe licensing used by the component (if specified)Optional
N/Asbom_exceptionIf included value is always trueOptional
N/Asbom_vuln_referenceIf this release resolves a specific vulnerability you can highlight a shared Vulnerability reference number(s)Optional
NTIA AttributeAsset AttributesMeaningRequirement
Author Namesbom_authorThe name of the Package AuthorRequired
Supplier Namesbom_supplierThe name of the Package SupplierRequired
Component Namesbom_component,(arc_display_name if appropriate)The name of the Software PackageRequired
Version Stringsbom_versionThe version of the Software PackageRequired
Unique Identifiersbom_uuidA unique identifier for the Package, DataTrails provides a Unique ID per asset but it may be preferred to include an existing internal reference insteadRequired
N/Asbom_repoLink to the Git Repo of the ComponentOptional
N/Asbom_release_notesLink to the release notes of the package versionOptional
N/Asbom_licenseThe licensing used by the component (if specified)Optional
Exception

When used in tandem with Release Plan and Accepted events the exception is a useful record of when an emergency has caused a release to be pushed without needing an initial approval or plan.

Release Plan and Release Accepted

Release events can be optionally enhanced by using ‘Release Plan’ and ‘Release Accepted’ events alongside them.

Release Plan events demonstrate an intent to introduce a new release, it should describe which version you want to release and who wants to release it. For example, it could include draft release notes explaining what is being updated and why it should be updated.

Release Accepted events demonstrate an approval on a Release Plan to go forward, it may be that the plan details a need to introduce a fix for a specific vulnerability and the security team is needed to sign off the release going forward.

These events are not essential to the process so can be omitted in a standard or minimal deployment but they are actively encouraged. As they should not affect the information about the latest Software Package Release there should be no Asset Attributes included, other NTIA attributes may also not be necessary or not available until release (e.g. Component Hash).

The Key Attribute that should be recorded is the version of the release that is being planned and accepted.

Release Plan

Release Plan Event Attribute Namespace

The sbom_planned_ prefix is used to designate attributes that are part of the event. Some of these are interpreted by DataTrails and others are guidelines.

NTIA AttributeEvent AttributesMeaningRequirement
N/Aarc_display_typeTells DataTrails how to interpret EventRequired, must set to Release Plan
Component Namesbom_planned_componentThe planned name of the PackageRequired
Version Stringsbom_planned_versionThe planned version of the PackageRequired
N/Asbom_planned_referenceA reference number for the plan (such as internal change request number)Required
N/Asbom_planned_dateThe planned release dateRequired
N/Asbom_planned_captainThe planned Release Captain (a common term for someone who is responsible for performing a Release; someone like an Owner in Agile serves a different purpose but may also be used if appropriate). This is mandatory as it describes who should be responsible for the releaseRequired
Author Namesbom_planned_authorThe planned name of the Package AuthorOptional
Supplier Namesbom_planned_supplierThe planned name of the Package SupplierOptional
Component Hashsbom_planned_hashThe planned hash of the component files/installation (per version)Optional
Unique Identifiersbom_planned_uuidThe planned unique identifier for the Package, DataTrails provides a Unique ID per asset but it may be preferred to include an existing internal reference insteadOptional
N/Asbom_planned_licenseIf there is an intended change to the license this may be neededOptional
N/Asbom_planned_vuln_referenceIf this release intends to resolve a specific vulnerability you can highlight a shared Vulnerability reference number(s)Optional

Release Accepted Event

Release Accepted Event Attribute Namespace

The sbom_accepted_ prefix is used to designate attributes that are part of the event. Some of these are interpreted by DataTrails and others are guidelines.

NTIA AttributeEvent AttributesMeaningRequirement
N/Aarc_display_typeTells DataTrails how to interpret EventRequired, must set to Release Accepted
Component Namesbom_accepted_componentThe accepted name of the PackageRequired
Version Stringsbom_accepted_versionThe accepted version of the PackageRequired
N/Asbom_accepted_referenceThe reference number of the associated planRequired
N/Asbom_accepted_dateThe accepted release dateRequired
N/Asbom_accepted_captainThe accepted Release Captain (a common term for someone who is responsible for performing a Release; someone like an Owner in Agile serves a different purpose but may also be used if appropriate). This is mandatory as it describes who should be responsible for the releaseRequired
N/Asbom_accepted_approverDescribes who has accepted the planRequired
Author Namesbom_accepted_authorThe accepted name of the Package AuthorOptional
Supplier Namesbom_accepted_supplierThe accepted name of the Package SupplierOptional
Component Hashsbom_accepted_hashThe accepted hash of the component files/installation (per version)Optional
Unique Identifiersbom_accepted_uuidThe accepted unique identifier for the Package, DataTrails provides a Unique ID per asset but it may be preferred to include an existing internal reference insteadOptional
N/Asbom_accepted_vuln_referenceIf this release intends to resolve a specific vulnerability you can highlight a shared Vulnerability reference number(s)Optional

Patch Event

Patches are often supplied to customer in an Out-Of-Band procedure to address critical bugs or vulnerabilities, usually with a short-term turnaround that can be outside the normal release cadence.

It is typically expected a Patch should contain its own SBOM separate to the Primary SBOM.

Patch Event Attribute Namespace

The sbom_patch_ prefix is used to designate attributes that are part of the event. Some of these are interpreted by DataTrails and others are guidelines.

NTIA AttributeEvent AttributesMeaningRequirement
N/Aarc_display_typeTells DataTrails how to interpret EventRequired, must set to Patch
Component Namesbom_patch_target_componentThe component the Patch targetsRequired
Version Stringsbom_patch_versionThe version string of the PatchRequired
Author Namesbom_patch_authorThe name of the Patch AuthorRequired
Supplier Namesbom_patch_supplierThe name of the Patch SupplierRequired
Component Hashsbom_patch_hashThe hash of the Patch files/installation (per version)Required
Unique Identifiersbom_patch_uuidThe accepted unique identifier for the Package, DataTrails provides a Unique ID per asset but it may be preferred to include an existing internal reference insteadRequired
N/Asbom_patch_target_versionThe version of the component the patch is targeted/built fromRequired
N/Asbom_patch_repoLink to the Git Repo/Fork/Branch of the Component (if different to the latest release repo)Optional
N/Asbom_patch_licenseThe licensing used by the component (if specified and different to the latest release license)Optional
N/Asbom_patch_vuln_referenceIf this patch resolves a specific vulnerability you can highlight a shared Vulnerability reference numberOptional

Vulnerability Disclosure and Update

These Event types are used for vulnerability management. -The first is to disclose knowledge of a vulnerability and the second is to update the status of the vulnerability after investigation is complete.

Vulnerability Disclosure Event Attribute Namespace

The vuln_ prefix is used to designate attributes that are part of the event. All of these are interpreted by DataTrails.

Vulnerability Disclosure

Event AttributesMeaningRequirement
arc_display_typeTells DataTrails how to interpret EventRequired, must set to Vulnerability Disclosure
vuln_nameFriendly Name for the VulnerabilityRequired
vuln_referenceReference Number (e.g. internal tracking number), useful when there may be multiple updates to a vulnerability during an investigation and for referencing when a particular release is expected to solve a vulnerabilityRequired
vuln_idSpecific ID of Vulnerability (e.g CVE-2018-0171)Required
vuln_categoryType of Vulnerability (e.g. CVE)Required
vuln_severitySeverity of Vulnerability (e.g. HIGH)Required
vuln_statusWhether the Vulnerability actually affects your component or is being investigated (e.g Known_not_affected)Required
vuln_authorAuthor of Vulnerability DisclosureRequired
vuln_target_componentAffected ComponentRequired
vuln_target_versionAffected Version(s)Required

Vulnerability Update

Event AttributesMeaningRequirement
arc_display_typeTells DataTrails how to interpret EventRequired, must set to Vulnerability Update
vuln_nameFriendly Name for the VulnerabilityRequired
vuln_referenceReference Number (e.g. internal tracking number), useful when there may be multiple updates to a vulnerability during an investigation and for referencing when a particular release is expected to solve a vulnerabilityRequired
vuln_idSpecific ID of Vulnerability (e.g CVE-2018-0171)Required
vuln_categoryType of Vulnerability (e.g. CVE)Required
vuln_severitySeverity of Vulnerability (e.g. HIGH)Required
vuln_statusWhether the Vulnerability actually affects your component or is being investigated (e.g Known_not_affected)Required
vuln_authorAuthor of Vulnerability DisclosureRequired
vuln_target_componentAffected ComponentRequired
vuln_target_versionAffected Version(s)Required

EOL Event

EOL Event Attribute Namespace

The sbom_eol_ prefix is used to designate attributes that are part of the event. All of these are interpreted by DataTrails.

An event to mark the Package as End of Life.

NTIA AttributeEvent AttributesMeaningRequirement
N/Aarc_display_typeTells DataTrails how to interpret EventRequired, must set to EOL
Component Namesbom_eol_target_componentThe component the EOL targetsRequired
Version Stringsbom_eol_target_versionThe version string affected by the EOLRequired
Author Namesbom_eol_authorThe name of the EOL AuthorRequired
Unique Identifiersbom_eol_uuidThe accepted unique identifier for the Package, DataTrails provides a Unique ID per asset but it may be preferred to include an existing internal reference insteadRequired
N/Asbom_eol_target_dateThe date on which the EOL will be activeRequired

← Document Profile
App Registrations API →
\ No newline at end of file +The first is to disclose knowledge of a vulnerability and the second is to update the status of the vulnerability after investigation is complete.

Vulnerability Disclosure Event Attribute Namespace

The vuln_ prefix is used to designate attributes that are part of the event. All of these are interpreted by DataTrails.

Vulnerability Disclosure

Event AttributesMeaningRequirement
arc_display_typeTells DataTrails how to interpret EventRequired, must set to Vulnerability Disclosure
vuln_nameFriendly Name for the VulnerabilityRequired
vuln_referenceReference Number (e.g. internal tracking number), useful when there may be multiple updates to a vulnerability during an investigation and for referencing when a particular release is expected to solve a vulnerabilityRequired
vuln_idSpecific ID of Vulnerability (e.g CVE-2018-0171)Required
vuln_categoryType of Vulnerability (e.g. CVE)Required
vuln_severitySeverity of Vulnerability (e.g. HIGH)Required
vuln_statusWhether the Vulnerability actually affects your component or is being investigated (e.g Known_not_affected)Required
vuln_authorAuthor of Vulnerability DisclosureRequired
vuln_target_componentAffected ComponentRequired
vuln_target_versionAffected Version(s)Required

Vulnerability Update

Event AttributesMeaningRequirement
arc_display_typeTells DataTrails how to interpret EventRequired, must set to Vulnerability Update
vuln_nameFriendly Name for the VulnerabilityRequired
vuln_referenceReference Number (e.g. internal tracking number), useful when there may be multiple updates to a vulnerability during an investigation and for referencing when a particular release is expected to solve a vulnerabilityRequired
vuln_idSpecific ID of Vulnerability (e.g CVE-2018-0171)Required
vuln_categoryType of Vulnerability (e.g. CVE)Required
vuln_severitySeverity of Vulnerability (e.g. HIGH)Required
vuln_statusWhether the Vulnerability actually affects your component or is being investigated (e.g Known_not_affected)Required
vuln_authorAuthor of Vulnerability DisclosureRequired
vuln_target_componentAffected ComponentRequired
vuln_target_versionAffected Version(s)Required

EOL Event

EOL Event Attribute Namespace

The sbom_eol_ prefix is used to designate attributes that are part of the event. All of these are interpreted by DataTrails.

An event to mark the Package as End of Life.

NTIA AttributeEvent AttributesMeaningRequirement
N/Aarc_display_typeTells DataTrails how to interpret EventRequired, must set to EOL
Component Namesbom_eol_target_componentThe component the EOL targetsRequired
Version Stringsbom_eol_target_versionThe version string affected by the EOLRequired
Author Namesbom_eol_authorThe name of the EOL AuthorRequired
Unique Identifiersbom_eol_uuidThe accepted unique identifier for the Package, DataTrails provides a Unique ID per asset but it may be preferred to include an existing internal reference insteadRequired
N/Asbom_eol_target_dateThe date on which the EOL will be activeRequired

← Document Profile
App Registrations API →
\ No newline at end of file diff --git a/developers/developer-patterns/verifying-with-simple-hash/index.html b/developers/developer-patterns/verifying-with-simple-hash/index.html index f30f97674..02cb90871 100644 --- a/developers/developer-patterns/verifying-with-simple-hash/index.html +++ b/developers/developer-patterns/verifying-with-simple-hash/index.html @@ -84,4 +84,4 @@ deactivate rm -rf simplehash-venv -
Note: If you are using an environment other than app.datatrails.ai, add the URL with the --fqdn option. For example, --fqdn "app.datatrails-poc.ai".

  • Compare the hash from your Transaction Details to the hash generated by the tool. If they match, your Event history has not changed.

    • ← Namespace
    Document Profile →
    \ No newline at end of file +
    Note: If you are using an environment other than app.datatrails.ai, add the URL with the --fqdn option. For example, --fqdn "app.datatrails-poc.ai".

  • Compare the hash from your Transaction Details to the hash generated by the tool. If they match, your Event history has not changed.

    • ← Namespace
    Document Profile →
    \ No newline at end of file diff --git a/developers/index.html b/developers/index.html index 938d017f7..65cf2db97 100644 --- a/developers/index.html +++ b/developers/index.html @@ -5,4 +5,4 @@

    Developers

    If you are a developer who is looking to easily add provenance to their data, this section is for you.
    You may be building a new application or looking for a way to add functionality to something that you already use every day.

    The DataTrails REST API, python SDK, or the YAML runner provide a simple way for you to integrate a provenance layer into your existing data platform so that you do not need to change the way that your users work.

    Check out the sub-sections below for more information!

    Developer Patterns →
    Go here for information on setting up an App Registration, requesting an Access Token together with other developer concepts and user profile descriptions.

    API Reference →
    The DataTrails REST API endpoint examples and definitions can be found here.

    YAML Runner Reference →
    The YAML reference contains information and examples for those who work with YAML files and would prefer to use this method to access the API.

    Additional resources are available from our Python SDK and the Python Samples.

    \ No newline at end of file +Sign Up

    Developers

    If you are a developer who is looking to easily add provenance to their data, this section is for you.
    You may be building a new application or looking for a way to add functionality to something that you already use every day.

    The DataTrails REST API, python SDK, or the YAML runner provide a simple way for you to integrate a provenance layer into your existing data platform so that you do not need to change the way that your users work.

    Check out the sub-sections below for more information!

    Developer Patterns →
    Go here for information on setting up an App Registration, requesting an Access Token together with other developer concepts and user profile descriptions.

    API Reference →
    The DataTrails REST API endpoint examples and definitions can be found here.

    YAML Runner Reference →
    The YAML reference contains information and examples for those who work with YAML files and would prefer to use this method to access the API.

    Additional resources are available from our Python SDK and the Python Samples.

    \ No newline at end of file diff --git a/developers/yaml-reference/assets/index.html b/developers/yaml-reference/assets/index.html index c6a309670..76696b8ff 100644 --- a/developers/yaml-reference/assets/index.html +++ b/developers/yaml-reference/assets/index.html @@ -83,4 +83,4 @@ description: Wait for all Assets in the wipp namespace to be confirmed attrs: arc_namespace: wipp -

    ← YAML Runner Components
    Events YAML Runner →
    \ No newline at end of file +

    ← YAML Runner Components
    Events YAML Runner →
    \ No newline at end of file diff --git a/developers/yaml-reference/compliance/index.html b/developers/yaml-reference/compliance/index.html index 6d10c5616..4ceeac24e 100644 --- a/developers/yaml-reference/compliance/index.html +++ b/developers/yaml-reference/compliance/index.html @@ -29,4 +29,4 @@ description: Check Compliance of EV pump 1. report: true asset_label: ev pump 1 -

    ← Subjects YAML Runner
    Estate Information YAML Runner →
    \ No newline at end of file +

    ← Subjects YAML Runner
    Estate Information YAML Runner →
    \ No newline at end of file diff --git a/developers/yaml-reference/estate-info/index.html b/developers/yaml-reference/estate-info/index.html index eb18f79a4..f6da8f34f 100644 --- a/developers/yaml-reference/estate-info/index.html +++ b/developers/yaml-reference/estate-info/index.html @@ -13,4 +13,4 @@ - step: action: COMPOSITE_ESTATE_INFO description: Estate Info Report -

    ← Compliance Policies YAML Runner
    Caps API →
    \ No newline at end of file +

    ← Compliance Policies YAML Runner
    Caps API →
    \ No newline at end of file diff --git a/developers/yaml-reference/events/index.html b/developers/yaml-reference/events/index.html index 4060750dd..48ec52bce 100644 --- a/developers/yaml-reference/events/index.html +++ b/developers/yaml-reference/events/index.html @@ -87,4 +87,4 @@ arc_display_type: open asset_attrs: arc_display_type: door -

    ← Assets YAML Runner
    Locations YAML Runner →
    \ No newline at end of file +

    ← Assets YAML Runner
    Locations YAML Runner →
    \ No newline at end of file diff --git a/developers/yaml-reference/index.html b/developers/yaml-reference/index.html index fcfb6800d..27495448f 100644 --- a/developers/yaml-reference/index.html +++ b/developers/yaml-reference/index.html @@ -5,4 +5,4 @@
    \ No newline at end of file +Sign Up
    \ No newline at end of file diff --git a/developers/yaml-reference/locations/index.html b/developers/yaml-reference/locations/index.html index 0059a0234..c6ab2684c 100644 --- a/developers/yaml-reference/locations/index.html +++ b/developers/yaml-reference/locations/index.html @@ -43,4 +43,4 @@ print_response: true attrs: director: John Smith -

    ← Events YAML Runner
    Subjects YAML Runner →
    \ No newline at end of file +

    ← Events YAML Runner
    Subjects YAML Runner →
    \ No newline at end of file diff --git a/developers/yaml-reference/story-runner-components/index.html b/developers/yaml-reference/story-runner-components/index.html index 0dabd3e5c..840605010 100644 --- a/developers/yaml-reference/story-runner-components/index.html +++ b/developers/yaml-reference/story-runner-components/index.html @@ -23,4 +23,4 @@ --client-id <your-client-id> \ --client-secret <your-client-secret> \ <path-to-yaml-file> -

    ← Tenancies API
    Assets YAML Runner →
    \ No newline at end of file +

    ← Tenancies API
    Assets YAML Runner →
    \ No newline at end of file diff --git a/developers/yaml-reference/subjects/index.html b/developers/yaml-reference/subjects/index.html index eff5f2582..9f2bd4708 100644 --- a/developers/yaml-reference/subjects/index.html +++ b/developers/yaml-reference/subjects/index.html @@ -90,4 +90,4 @@ print_response: true subject_label: A subject `` -

    ← Locations YAML Runner
    Compliance Policies YAML Runner →
    \ No newline at end of file +

    ← Locations YAML Runner
    Compliance Policies YAML Runner →
    \ No newline at end of file diff --git a/glossary/common-datatrails-terms/index.html b/glossary/common-datatrails-terms/index.html index e257f3944..815e02f66 100644 --- a/glossary/common-datatrails-terms/index.html +++ b/glossary/common-datatrails-terms/index.html @@ -8,4 +8,4 @@

    Common DataTrails Terms

    Select a term for more information.

    TermDefinition
    ABACAttribute-Based Access Control; policy that allows you to grant fine-grain access to members of your Tenancy
    access policygrants chosen Asset and Event access to stakeholders
    actorperson/machine/software integration that created a particular entry on the provenance record
    administratoruser with permission to see all Asset and Event information within a Tenancy, and to grant access to other users
    anchoredSimple Hash events are committed to the blockchain by hashing them in batches. The hash recorded on the chain is called the anchor
    asseta DataTrails Asset is an entry in your tenancy, which has a collection of attributes that describes its current state and a complete life history of Events
    asset attributeskey-value pairs that represent information about an Asset
    asset IDthe permanent unique identifier for an Asset, under which all provenance information (Events) can be found
    audit traila formal record of activities (Events) that are made against a piece of data (an Asset)
    bearer tokenaccess token for DataTrails API; created using Custom Integration credentials
    behaviorsdetail what class of events in an Asset lifecycle you might wish to record
    compliance policyuser-defined rule sets that Assets can be tested against
    custom integrationclient ID and client secret credentials that are used to access the DataTrails API. Formerly known as an App Registration
    document hashcryptographic ‘fingerprint’ of a file or document that proves it is unmodified
    document statuswhen dealing with Document profile Assets in DataTrails you can attach certain lifecycle stage metadata to them such as ‘Draft’, ‘Published’, or ‘Withdrawn’ in order to properly convey whether or not someone checking provenance of the document should rely on a particular version
    eventtracks key moments of an Asset lifecycle; details of Who Did What When to an Asset
    event attributeskey-value pairs that represent information about an Event
    event IDunique identifier for an entry in the provenance record that means it can be shared and found later
    event typeevents in DataTrails are labeled with a ’type’ that signify what kind of evidence they relate to, for instance a ‘Publish’ event on a document, or a ‘Shipping’ event on physical goods. Event types can be very useful for defining access control rules as well as filtering the audit trail for specific kinds of information
    integrationbuilt-in API functionality that allows DataTrails to connect to third party products such as Dropbox
    linked foldera folder that has been selected to be linked to DataTrails during the configuration of an Integration
    metadatastructured information about a file. In DataTrails this metadata is recorded in the Asset and Event attributes
    OBACOrganization-Based Access Control; policy allows sharing with the Administrator of another organization
    operationclass of Event being recorded
    organizationany entity with a distinct DataTrails account who publishes or verifies provenance information on the platform
    principal_acceptedthe actual user principal information belonging to the credential used to access the DataTrails REST interface
    principal_declaredan optional user-supplied value that tells who performed an Event
    proof mechanismmethod by which information on the DataTrails blockchain can be verified; selected when an Asset is created
    provenancethe version and ownership history of a piece of data. With DataTrails this is an immutable audit trail to prove Who Did What When to any piece of data
    public assetAssets that can be used to publicly assert data, accessible by URL without the need for a DataTrails account
    selectoridentifying attribute the Yaml Runner will use to check if your Asset exists already before attempting to create it
    simple hashProof Mechanism that commits information to the DataTrails blockchain in batches; value can confirm that information in the batch has not changed
    tenancyan organization’s private area within DataTrails, containing Asset and Event data
    tenant display namedisplayed only within own Tenancy for easy identification and switching
    tenant_acceptedthe time an event was actually received on the DataTrails REST interface
    tenant_committedthe time an event was confirmed distributed to all DLT nodes in the value chain
    tenant_declaredan optional user-supplied value that tells when an Event happened
    transactionfinal commitment of data to the Distributed Ledger Technology so that it is sealed and cannot be modifed, tampered or erased
    unlinked foldera folder that has not been selected to be linked to DataTrails during the configuration or reconfiguration of an Integration
    verified domaintenancy name visible to others in place of the tenancy ID when viewing the Asset Overview of a public Asset or a shared private Asset. Must be verified by the DataTrails team
    verified organizationan organization which has paid to have their domain verified and displayed in place of their tenancy ID in Instaproof results and in the Asset Overview
    versionwhen dealing with Document profile Assets in DataTrails you can differentiate ‘final’ or ‘published’ versions of a document from other provenance information such as reviews or downloads

    Reserved Attributes →
    \ No newline at end of file +Glossary

    Common DataTrails Terms

    Select a term for more information.

    TermDefinition
    ABACAttribute-Based Access Control; policy that allows you to grant fine-grain access to members of your Tenancy
    access policygrants chosen Asset and Event access to stakeholders
    actorperson/machine/software integration that created a particular entry on the provenance record
    administratoruser with permission to see all Asset and Event information within a Tenancy, and to grant access to other users
    anchoredSimple Hash events are committed to the blockchain by hashing them in batches. The hash recorded on the chain is called the anchor
    asseta DataTrails Asset is an entry in your tenancy, which has a collection of attributes that describes its current state and a complete life history of Events
    asset attributeskey-value pairs that represent information about an Asset
    asset IDthe permanent unique identifier for an Asset, under which all provenance information (Events) can be found
    audit traila formal record of activities (Events) that are made against a piece of data (an Asset)
    bearer tokenaccess token for DataTrails API; created using Custom Integration credentials
    behaviorsdetail what class of events in an Asset lifecycle you might wish to record
    compliance policyuser-defined rule sets that Assets can be tested against
    custom integrationclient ID and client secret credentials that are used to access the DataTrails API. Formerly known as an App Registration
    document hashcryptographic ‘fingerprint’ of a file or document that proves it is unmodified
    document statuswhen dealing with Document profile Assets in DataTrails you can attach certain lifecycle stage metadata to them such as ‘Draft’, ‘Published’, or ‘Withdrawn’ in order to properly convey whether or not someone checking provenance of the document should rely on a particular version
    eventtracks key moments of an Asset lifecycle; details of Who Did What When to an Asset
    event attributeskey-value pairs that represent information about an Event
    event IDunique identifier for an entry in the provenance record that means it can be shared and found later
    event typeevents in DataTrails are labeled with a ’type’ that signify what kind of evidence they relate to, for instance a ‘Publish’ event on a document, or a ‘Shipping’ event on physical goods. Event types can be very useful for defining access control rules as well as filtering the audit trail for specific kinds of information
    integrationbuilt-in API functionality that allows DataTrails to connect to third party products such as Dropbox
    linked foldera folder that has been selected to be linked to DataTrails during the configuration of an Integration
    metadatastructured information about a file. In DataTrails this metadata is recorded in the Asset and Event attributes
    OBACOrganization-Based Access Control; policy allows sharing with the Administrator of another organization
    operationclass of Event being recorded
    organizationany entity with a distinct DataTrails account who publishes or verifies provenance information on the platform
    principal_acceptedthe actual user principal information belonging to the credential used to access the DataTrails REST interface
    principal_declaredan optional user-supplied value that tells who performed an Event
    proof mechanismmethod by which information on the DataTrails blockchain can be verified; selected when an Asset is created
    provenancethe version and ownership history of a piece of data. With DataTrails this is an immutable audit trail to prove Who Did What When to any piece of data
    public assetAssets that can be used to publicly assert data, accessible by URL without the need for a DataTrails account
    selectoridentifying attribute the Yaml Runner will use to check if your Asset exists already before attempting to create it
    simple hashProof Mechanism that commits information to the DataTrails blockchain in batches; value can confirm that information in the batch has not changed
    tenancyan organization’s private area within DataTrails, containing Asset and Event data
    tenant display namedisplayed only within own Tenancy for easy identification and switching
    tenant_acceptedthe time an event was actually received on the DataTrails REST interface
    tenant_committedthe time an event was confirmed distributed to all DLT nodes in the value chain
    tenant_declaredan optional user-supplied value that tells when an Event happened
    transactionfinal commitment of data to the Distributed Ledger Technology so that it is sealed and cannot be modifed, tampered or erased
    unlinked foldera folder that has not been selected to be linked to DataTrails during the configuration or reconfiguration of an Integration
    verified domaintenancy name visible to others in place of the tenancy ID when viewing the Asset Overview of a public Asset or a shared private Asset. Must be verified by the DataTrails team
    verified organizationan organization which has paid to have their domain verified and displayed in place of their tenancy ID in Instaproof results and in the Asset Overview
    versionwhen dealing with Document profile Assets in DataTrails you can differentiate ‘final’ or ‘published’ versions of a document from other provenance information such as reviews or downloads

    Reserved Attributes →
    \ No newline at end of file diff --git a/glossary/index.html b/glossary/index.html index 4fdeecd73..6e6979f27 100644 --- a/glossary/index.html +++ b/glossary/index.html @@ -5,4 +5,4 @@

    Glossary

    Select an option to to find out more about the terms used by DataTrails.

    • Common DataTrails Terms: A list of terms used by DataTrails.
    • Reserved Attributes: A list of Asset attributes that are used by the DataTrails platform and have a specific purpose.

    \ No newline at end of file +Sign Up

    Glossary

    Select an option to to find out more about the terms used by DataTrails.

    • Common DataTrails Terms: A list of terms used by DataTrails.
    • Reserved Attributes: A list of Asset attributes that are used by the DataTrails platform and have a specific purpose.

    \ No newline at end of file diff --git a/glossary/reserved-attributes/index.html b/glossary/reserved-attributes/index.html index 1cc62bc7c..d222be57b 100644 --- a/glossary/reserved-attributes/index.html +++ b/glossary/reserved-attributes/index.html @@ -10,4 +10,4 @@

    Reserved Attributes

    Reserved attributes are asset attributes that are used by the DataTrails platform and have a specific purpose. All reserved attributes have the arc_ prefix.

    Select an attribute to see an example of it in use.

    Asset Attributes

    AttributeMeaning
    arc_descriptionbrief description of Asset or Event being recorded
    arc_display_namefriendly name identifier for Assets, Events, and policies
    arc_display_typeclassification of the type of Asset being traced that can be used for grouping or access control
    arc_home_location_identityphysical location to which an Asset nominally ‘belongs’. NOT related to the Asset’s position in space. For that, use arc_gis_* (below)
    arc_primary_imagean image attachment that will display as the thumbnail of an Asset

    Event Attributes

    AttributeMeaning
    arc_correlation_valuelinks Events together for evaluation in Compliance Policies
    arc_gis_lattags the Event as having happened at a particular latitude. Used in the DataTrails UI for mapping
    arc_gis_lngtags the Event as having happened at a particular longitude. Used in the DataTrails UI for mapping
    arc_descriptionbrief description of the Event being recorded
    arc_display_typeclassification of the type of Event being performed that can be used for grouping or access control
    arc_primary_imagean image attachment that will display as the thumbnail of the Event

    ← Common DataTrails Terms
    \ No newline at end of file +Glossary

    Reserved Attributes

    Reserved attributes are asset attributes that are used by the DataTrails platform and have a specific purpose. All reserved attributes have the arc_ prefix.

    Select an attribute to see an example of it in use.

    Asset Attributes

    AttributeMeaning
    arc_descriptionbrief description of Asset or Event being recorded
    arc_display_namefriendly name identifier for Assets, Events, and policies
    arc_display_typeclassification of the type of Asset being traced that can be used for grouping or access control
    arc_home_location_identityphysical location to which an Asset nominally ‘belongs’. NOT related to the Asset’s position in space. For that, use arc_gis_* (below)
    arc_primary_imagean image attachment that will display as the thumbnail of an Asset

    Event Attributes

    AttributeMeaning
    arc_correlation_valuelinks Events together for evaluation in Compliance Policies
    arc_gis_lattags the Event as having happened at a particular latitude. Used in the DataTrails UI for mapping
    arc_gis_lngtags the Event as having happened at a particular longitude. Used in the DataTrails UI for mapping
    arc_descriptionbrief description of the Event being recorded
    arc_display_typeclassification of the type of Event being performed that can be used for grouping or access control
    arc_primary_imagean image attachment that will display as the thumbnail of the Event

    ← Common DataTrails Terms
    \ No newline at end of file diff --git a/index.html b/index.html index 4c94e1a22..aa222a4b4 100644 --- a/index.html +++ b/index.html @@ -5,4 +5,4 @@
    \ No newline at end of file +Sign Up
    \ No newline at end of file diff --git a/index.min.ebf5c7d2301df869846c3757d5663662b88cbb785c50fff280a96a20de115aa5c994fb502e67eb8b3851b56d2bde059b349566ded6e10fce615cb67cbbf4d0f2.js b/index.min.f2a0b4d14203872f118ad434044411eba08754978e87a468a4f65ff2d6845ea89f532a5dafdd10af1f88145af81349d5f71a8f541ac4f6cc6bd4494582ef0f9d.js similarity index 99% rename from index.min.ebf5c7d2301df869846c3757d5663662b88cbb785c50fff280a96a20de115aa5c994fb502e67eb8b3851b56d2bde059b349566ded6e10fce615cb67cbbf4d0f2.js rename to index.min.f2a0b4d14203872f118ad434044411eba08754978e87a468a4f65ff2d6845ea89f532a5dafdd10af1f88145af81349d5f71a8f541ac4f6cc6bd4494582ef0f9d.js index 5d341c419..123015f8c 100644 --- a/index.min.ebf5c7d2301df869846c3757d5663662b88cbb785c50fff280a96a20de115aa5c994fb502e67eb8b3851b56d2bde059b349566ded6e10fce615cb67cbbf4d0f2.js +++ b/index.min.f2a0b4d14203872f118ad434044411eba08754978e87a468a4f65ff2d6845ea89f532a5dafdd10af1f88145af81349d5f71a8f541ac4f6cc6bd4494582ef0f9d.js @@ -413,10 +413,16 @@ This has many use cases relating to content authenticity but can also be applied -`},{id:3,href:"https://docs.datatrails.ai/platform/overview/advanced-concepts/",title:"Advanced Concepts",description:"DataTrails Advanced Concepts",content:`

    Assets

    -

    Central to all DataTrails operations are Assets. These are the records that represent the collective ‘Golden Thread’ of evidence contributed by all stakeholders about a particular thing. Assets can represent anything: a physical object, a smart device, or even a business process. As long as shared accountability needs to be traced and trustworthy, it can be recorded as a DataTrails Asset.

    +`},{id:3,href:"https://docs.datatrails.ai/platform/overview/advanced-concepts/",title:"Advanced Concepts",description:"DataTrails Advanced Concepts",content:`

    Assets and Events

    +

    The core tenets of the DataTrails platform are Assets and Events. These are the records that represent the collective ‘Golden Thread’ of evidence contributed by all stakeholders about a particular thing.

    +

    Assets can represent anything: a file, a piece of data, a physical thing or even a business process. As long as shared accountability needs to be traced and trustworthy, it can be recorded as a DataTrails Asset.

    +

    Events are a way to provide updates to Assets, building a historical view of the Asset, what has happened and how it got into its current state. These updates in events can be changes to the thing itself, custody of the thing, or even an observation of an interaction with the thing.
    +Any interaction with the thing can be significant, from user logins to unexpected restarts or ad-hoc observations. Keeping a record of these Events can build up a picture of how an Asset came to be in its current state and provides crucial insight to future maintenance staff, auditors, and security remediation teams.

    +

    Knowing the current state of an Asset isn’t enough: sure, it has software version 3.0 now but when was that installed? Before the major incident? After the major incident? This morning before the support call? By recording events into an immutable audit trail, questions relating to that asset can be answered.

    DataTrails Assets are essentially very simple: a collection of attributes that describe the Asset expressed as a standard JSON document. The power of the system comes from the fact that those attributes come with complete traceable provenance and are guaranteed to appear the same to every stakeholder, creating a single source of truth for shared business processes.

    -

    DataTrails is not opinionated about Asset content, meaning that attributes can trace anything deemed important to participants. Much like #hashtags on Twitter, they can be invented by anyone at any time, but once an attribute has been seen once it will be fully traced from that point on.

    +

    DataTrails is not opinionated about Asset content, meaning that attributes can trace anything deemed important to participants. Much like #hashtags on social media platforms, they can be invented by anyone at any time, but once an attribute has been seen once it will be fully traced from that point on.

    +

    DataTrails ensures complete and tamper-proof lineage and provenance for all Asset attributes by enforcing a simple rule: +The only way to change an Asset attribute is through an Event that records Who Did What When to make that change.

    A simple Asset might look like this:

       {
       // Fixed global identity for this Asset
@@ -471,13 +477,6 @@ This has many use cases relating to content authenticity but can also be applied
 
    
     
     Caution: Untracking an Asset does not remove it or its Event history from the system; all stakeholders who previously had access to the record will continue to have access to the Event history, including the untracking event, if they look for it.
    
   
    
-
    For more detailed information on Assets and how to implement them, please refer to 
-the Assets API Reference.
    
-
    Events
    
-
    Any interaction with a device can be significant, from user logins to unexpected restarts or ad-hoc observations. Keeping a record of these Events can build up a picture of how an Asset came to be in its current state and provides crucial insight to future maintenance staff, auditors, and security remediation teams.
    
-
    Knowing the current state of an Asset isn’t enough: sure, it has software version 3.0 now but when was that installed? Before the major incident? After the major incident? This morning before the support call?
    
-
    DataTrails ensures complete and tamper-proof lineage and provenance for all Asset attributes by enforcing a simple rule:
-The only way to change an Asset attribute is through an Event that records Who Did What When to make that change.
    
 
    Timestamps on Events
    
 
    Lifecycle events in DataTrails give stakeholders a shared view of “Who did What When to an Asset". The “What” and the “Asset” are quite straightforward, but the “When” and “Who” can be more nuanced.
    
 
    Once committed to the DataTrails system, each lifecycle Event record carries 3 separate timestamps:
    
@@ -494,18 +493,13 @@ This has many use cases relating to content authenticity but can also be applied
 
  • principal_declared - an optional user-supplied value that tells who performed an Event. This is useful for cases where the user principal/credential used to authorize the Event does not accurately or usefully reflect the real-world agent (eg a multi-user application with device-based credentials).
    • 
 
  • principal_accepted - the actual user principal information belonging to the credential used to access the DataTrails REST interface. Set by the system and retrieved from the authorizing IDP, cannot be changed by the client.
    • 
 
-
    For more detailed information on Events and how to implement them, please refer to 
-the Events API Reference.
    
+
    For more detailed information on Events, and how to implement them, please refer to the 
+Events API Reference.
    
 
    Proof Mechanisms
    
 
    Assets and Events are core to the DataTrails platform, and being able to quickly demonstrate proof that these artifacts have not been tampered is key to being able to use them.
    
 
    When 
-creating an Asset, a proof mechanism will be used for that Asset and its Events. This determines how your data is recorded on the DataTrails blockchain.
    
-
    Simple Hash
    
-
    Simple Hash takes all the Events within a past time period (the default is the last 30 days) and commits them to the blockchain as one hash. This hash value can then be used to compare the current state of the Asset, and identify if any changes have occurred. With Simple Hash, you will not be able to see exactly what those changes were, only that something has changed.
    
-
    
-    
     Note: The Simple Hash proof mechanism is available with 
-all tiers of the DataTrails platform.
    
-  
    
+creating an Asset, DataTrails uses a proof mechanism for that Asset and its Events. This determines how your data is recorded on the DataTrails blockchain.
    
+
    Our Simple Hash proof mechanism takes all the Events within a past time period (the default is the last 30 days) and commits them to the blockchain as one hash. This hash value can then be used to compare the current state of the Asset, and identify if any changes have occurred. With Simple Hash, you will not be able to see exactly what those changes were, only that something has changed.
    
 
    Access Policies
    
 
    Sharing the right amount of information with your value chain partners is critical to creating a trustworthy shared history for Assets. It is important that every participant be able to see and contribute to the management of Assets without compromising security, commercial, or private personal information. For example, competing vendors should not see each other’s information, but both should be able to freely collaborate with their mutual customer or industry regulator.
    
 
    In other scenarios, it is desirable to share basic maintenance information with a vendor or external maintenance company, whilst restricting critical operating information such as run cycles and cyber SLAs to a much smaller group.
    
@@ -515,6 +509,12 @@ This has many use cases relating to content authenticity but can also be applied
 
    This one-time manual process helps to underpin trust and security in your DataTrails Access Policies by ensuring that the partners represented in them are the ones you expect.
    +

    Public Attestations

    +

    While a strict, 1-to-1 relationship might be desirable for some use cases, it is also possible that a recorded asset and associated events are recorded in a more widely accessible way. With the use of our Public setting for an asset, you can create an access policy which enables anyone to view that asset record. A viewer of that asset does not have to be registered with DataTrails, and can anonymously use our +Instaproof service to check the thing they have against the public record in DataTrails.

    +
    +
    Note: Instaproof uses the hash of a file, piece of data or digital artifact to check for associated records with that hash value. This enables users to quickly check if the thing they have is the correct, unaltered version they are expecting.
    +

    Considerations

    As with any system handling large amounts of important data, one must carefully consider the design and scope of Access Policy rules in DataTrails. Every situation is different, and the DataTrails Access Policy system is flexible and powerful enough to support most situations, but in general it is recommended to follow some basic rules:

    @@ -525,7 +525,9 @@ Every situation is different, and the DataTrails Access Policy system is flexibl
  • Remember attributes can change: ABAC policies are applied at time of access request, not at time of creation, so changing attributes on an asset may change which access policies apply to it. This is one of the primary advantages to an ABAC system, but needs to be kept in mind when designing access control processes.

    • Access Policy configuration

    -

    DataTrails employs a principle called Attribute-Based Access Control (ABAC) for users within an organization, and a related concept called Organization-Based Access Control (OBAC) to mediate data sharing between value chain participants.

    +

    DataTrails employs a principle called Attribute-Based Access Control (ABAC) for users within an organization who are given +internal access to your tenant. A related concept called Organization-Based Access Control (OBAC) is provided to mediate data sharing between value chain participants who will share +external access to their tenants.

    Rather than applying a specific fixed policy to each Asset, or grouping them into rigid hierarchies, Access Policies are defined in terms of the observable properties (or attributes) of Assets and users, and if both match, the policy is applied. This enables much greater flexibility and expressivity than traditional hierarchical or role-based methods, whilst at the same time reducing complexity in defining sharing in large-scale systems.

    DataTrails Access Policies comprise of 2 main parts:

    Access Policy configuration

    -

    DataTrails employs a principle called Attribute-Based Access Control (ABAC) for users within an organization, and a related concept called Organization-Based Access Control (OBAC) to mediate data sharing between value chain participants.

    +

    DataTrails employs a principle called Attribute-Based Access Control (ABAC) for users within an organization who are given +internal access to your tenant. A related concept called Organization-Based Access Control (OBAC) is provided to mediate data sharing between value chain participants who will share +external access to their tenants.

    Rather than applying a specific fixed policy to each Asset, or grouping them into rigid hierarchies, Access Policies are defined in terms of the observable properties (or attributes) of Assets and users, and if both match, the policy is applied. This enables much greater flexibility and expressivity than traditional hierarchical or role-based methods, whilst at the same time reducing complexity in defining sharing in large-scale systems.

    DataTrails Access Policies comprise of 2 main parts:

    \ No newline at end of file diff --git a/platform/administration/sharing-access-inside-your-tenant/index.html b/platform/administration/sharing-access-inside-your-tenant/index.html index 891e979c6..d0f145da8 100644 --- a/platform/administration/sharing-access-inside-your-tenant/index.html +++ b/platform/administration/sharing-access-inside-your-tenant/index.html @@ -113,4 +113,4 @@ -H "Content-type: application/json" \ -d "@/path/to/jsonfile" \ https://app.datatrails.ai/archivist/iam/v1/access_policies -

  • Check the Asset is appropriately shared

    Mandy should only be allowed to see the Asset’s name, type, image, length, and weight attributes.

    Mandy's view as a Non-Administrator

    For comparison with our Administrator, Jill who can see everything:

    Jill's view as a Administrator

    • We can see that Mandy can only view the Attributes specified in the policy.

    Our Administrator, Jill, can see every detail associated with the Asset.

    ← Verified Domain
    Managing External Access to Your Tenant →
    \ No newline at end of file +

  • Check the Asset is appropriately shared

    Mandy should only be allowed to see the Asset’s name, type, image, length, and weight attributes.

    Mandy's view as a Non-Administrator

    For comparison with our Administrator, Jill who can see everything:

    Jill's view as a Administrator

    • We can see that Mandy can only view the Attributes specified in the policy.

    Our Administrator, Jill, can see every detail associated with the Asset.

    ← Verified Domain
    Managing External Access to Your Tenant →
    \ No newline at end of file diff --git a/platform/administration/sharing-access-outside-your-tenant/index.html b/platform/administration/sharing-access-outside-your-tenant/index.html index 3e6b6890f..897982e34 100644 --- a/platform/administration/sharing-access-outside-your-tenant/index.html +++ b/platform/administration/sharing-access-outside-your-tenant/index.html @@ -121,4 +121,4 @@ -d "@/path/to/jsonfile" \ https://app.datatrails.ai/archivist/iam/v1/access_policies

  • Once complete, check the Asset is shared appropriately; Mandy should only be able to see the Name, Type and an Image of the container as well as the Asset’s custom weight and length attributes.

    Mandy's view as an Administrator of the External Organization
    By comparison, our Administrator, Jill, can see the full details of the Asset:
    Jill's view as an Administrator

  • If Mandy wishes to share what she can to Non-Administrators within her organization, it is her responsibility to create an ABAC Policy as she would any other Asset she has access to.

    There are many possible fine-grained controls and as such ABAC and OBAC Policy Creation is an extensive topic. To find out more, head over to the -IAM Policies API Reference.

    • ← Managing Internal Access to Your Tenant
    Dropbox Integration →
    \ No newline at end of file +IAM Policies API Reference.

    ← Managing Internal Access to Your Tenant
    Dropbox Integration →
    \ No newline at end of file diff --git a/platform/administration/verified-domain/index.html b/platform/administration/verified-domain/index.html index 3139e09b4..7c78cab7a 100644 --- a/platform/administration/verified-domain/index.html +++ b/platform/administration/verified-domain/index.html @@ -11,4 +11,4 @@ Tenant Display Name. Tenant display names are internal, appearing only within your own Tenancy, and are not visible to anyone you share with. A verified domain name must be set by the DataTrails team, and will be visible to actors outside your Tenancy.

    Why is it important to verify my organization’s domain?

    Getting your organization’s domain verified indicates that you are who you say you are. This helps close the trust gap inherent to information sharing between organizations or with the public.

    Without domain verification, the Organization is noted as the publisher’s Tenant ID. Verifying your domain not only shows that this information comes from a legitimate actor on behalf of the organization, but also replaces the Tenant ID with your domain name so consumers can more easily identify the publishing organization. For example, someone attesting information on behalf of DataTrails would have datatrails.ai.

    Organization without Verified Domain
    Organization with Verified Domain

    How can I get my organization’s domain verified?

    The DataTrails team is happy to help you obtain your verified domain badge. Please contact support@datatrails.ai from an email address which includes the domain you wish to verify. For example, email us from @datatrails.ai to verify the datatrails.ai domain. We will send you a confirmation email to make sure that the details are correct.

    In order to protect our user community, it is important for us to verify that the person making the request is authorized to do so by the owner of the domain. We will carry out some internal checks based on the information that we have been given and we may request further evidence from you to prove that you own or control the domain in question. Typically, this will be in the form of public company information or domain registration records. Please be prepared to share this evidence with us.

    Checking the Verified Domain of an External Organization

    If an organization has a verified domain with DataTrails, it will be displayed when you view a Public Asset they have published. You may also retrieve this information via the API if you know the organization’s Tenant ID.

    curl -v -X GET \
      -H "@$HOME/.datatrails/bearer-token.txt" \
      https://app.datatrails.ai/archivist/v1/tenancies/{uuid}:publicinfo
-

    ← Identity and Access Management
    Managing Internal Access to Your Tenant →
    \ No newline at end of file +

    ← Identity and Access Management
    Managing Internal Access to Your Tenant →
    \ No newline at end of file diff --git a/platform/index.html b/platform/index.html index 3e32fb139..16817e6b2 100644 --- a/platform/index.html +++ b/platform/index.html @@ -5,4 +5,4 @@

    Platform

    If you are new to DataTrails, this is the place to start.

    The foundations of understanding the DataTrails platform are explained in the Overview. This will introduce the basic (and not so basic) concepts and take you through creating your first Asset and registering the first Event of your audit trail.

    The Administration section will show you how to manage your Tenancy and control access to your Assets.

    Check out the sub-sections below for more information!

    Overview →
    Core concepts and tasks
    Administration →
    Create users, set access rights and share Assets
    \ No newline at end of file +Sign Up

    Platform

    If you are new to DataTrails, this is the place to start.

    The foundations of understanding the DataTrails platform are explained in the Overview. This will introduce the basic (and not so basic) concepts and take you through creating your first Asset and registering the first Event of your audit trail.

    The Administration section will show you how to manage your Tenancy and control access to your Assets.

    Check out the sub-sections below for more information!

    Overview →
    Core concepts and tasks
    Administration →
    Create users, set access rights and share Assets
    \ No newline at end of file diff --git a/platform/overview/advanced-concepts/index.html b/platform/overview/advanced-concepts/index.html index 3b7da9b89..ce93fdbca 100644 --- a/platform/overview/advanced-concepts/index.html +++ b/platform/overview/advanced-concepts/index.html @@ -1,5 +1,5 @@ Advanced Concepts - DataTrails -
    +
    DataTrails

    Advanced Concepts

    This section goes into detail on the topics covered in Core Concepts, as well as additional advanced topics.

    Assets

    Central to all DataTrails operations are Assets. These are the records that represent the collective ‘Golden Thread’ of evidence contributed by all stakeholders about a particular thing. Assets can represent anything: a physical object, a smart device, or even a business process. As long as shared accountability needs to be traced and trustworthy, it can be recorded as a DataTrails Asset.

    DataTrails Assets are essentially very simple: a collection of attributes that describe the Asset expressed as a standard JSON document. The power of the system comes from the fact that those attributes come with complete traceable provenance and are guaranteed to appear the same to every stakeholder, creating a single source of truth for shared business processes.

    DataTrails is not opinionated about Asset content, meaning that attributes can trace anything deemed important to participants. Much like #hashtags on Twitter, they can be invented by anyone at any time, but once an attribute has been seen once it will be fully traced from that point on.

    A simple Asset might look like this:

       {
+Administration

    Advanced Concepts

    This section goes into more detail on some the subjects covered in Core Concepts, as well as introducing additional advanced topics.

    Assets and Events

    The core tenets of the DataTrails platform are Assets and Events. These are the records that represent the collective ‘Golden Thread’ of evidence contributed by all stakeholders about a particular thing.

    Assets can represent anything: a file, a piece of data, a physical thing or even a business process. As long as shared accountability needs to be traced and trustworthy, it can be recorded as a DataTrails Asset.

    Events are a way to provide updates to Assets, building a historical view of the Asset, what has happened and how it got into its current state. These updates in events can be changes to the thing itself, custody of the thing, or even an observation of an interaction with the thing.
    Any interaction with the thing can be significant, from user logins to unexpected restarts or ad-hoc observations. Keeping a record of these Events can build up a picture of how an Asset came to be in its current state and provides crucial insight to future maintenance staff, auditors, and security remediation teams.

    Knowing the current state of an Asset isn’t enough: sure, it has software version 3.0 now but when was that installed? Before the major incident? After the major incident? This morning before the support call? By recording events into an immutable audit trail, questions relating to that asset can be answered.

    DataTrails Assets are essentially very simple: a collection of attributes that describe the Asset expressed as a standard JSON document. The power of the system comes from the fact that those attributes come with complete traceable provenance and are guaranteed to appear the same to every stakeholder, creating a single source of truth for shared business processes.

    DataTrails is not opinionated about Asset content, meaning that attributes can trace anything deemed important to participants. Much like #hashtags on social media platforms, they can be invented by anyone at any time, but once an attribute has been seen once it will be fully traced from that point on.

    DataTrails ensures complete and tamper-proof lineage and provenance for all Asset attributes by enforcing a simple rule: +The only way to change an Asset attribute is through an Event that records Who Did What When to make that change.

    A simple Asset might look like this:

       {
       // Fixed global identity for this Asset
       "identity": "assets/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
 
@@ -51,13 +52,13 @@
       "owner": "0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
       "storage_integrity": "LEDGER"
     }
-
    Note: The Asset Identity is fixed and constant for the life of the Asset and across all stakeholders. This ensures easy traceability and assurance that all stakeholders are collaborating on the same object and see the same complete history of Events.

    Deleting Assets (untracking)

    An essential value of storing evidence in DataTrails is that data is always available to stakeholders and cannot be shredded or manipulated later. Given this, it is not possible to actually delete Assets from the system, but there will be cases where it is desirable to hide Assets in the UI or omit them from default searches or compliance queries (for instance as a result of decommissioning or disposal of the corresponding physical asset).

    To accommodate this need DataTrails separates the Asset estate into 2 classes: tracked Assets (those that are interesting to the system and actively recording events) and untracked Assets (those that are no longer actively interesting). When for any reason it becomes desirable to remove an Asset, the Asset owner can make it untracked so that it does not appear in lists or searches.

    Caution: Untracking an Asset does not remove it or its Event history from the system; all stakeholders who previously had access to the record will continue to have access to the Event history, including the untracking event, if they look for it.

    For more detailed information on Assets and how to implement them, please refer to -the Assets API Reference.

    Events

    Any interaction with a device can be significant, from user logins to unexpected restarts or ad-hoc observations. Keeping a record of these Events can build up a picture of how an Asset came to be in its current state and provides crucial insight to future maintenance staff, auditors, and security remediation teams.

    Knowing the current state of an Asset isn’t enough: sure, it has software version 3.0 now but when was that installed? Before the major incident? After the major incident? This morning before the support call?

    DataTrails ensures complete and tamper-proof lineage and provenance for all Asset attributes by enforcing a simple rule: -The only way to change an Asset attribute is through an Event that records Who Did What When to make that change.

    Timestamps on Events

    Lifecycle events in DataTrails give stakeholders a shared view of “Who did What When to an Asset". The “What” and the “Asset” are quite straightforward, but the “When” and “Who” can be more nuanced.

    Once committed to the DataTrails system, each lifecycle Event record carries 3 separate timestamps:

    • timestamp_declared - an optional user-supplied value that tells when an Event happened. This is useful for cases where the client system is off-line for a period but the user still wishes to record the accurate time and order of activities (eg inspection rounds in an air-gapped facility). If unspecified, the system sets timestamp_declared equal to timestamp_accepted (see below).
    • timestamp_accepted - the time the event was actually received on the DataTrails REST interface. Set by the system, cannot be changed by the client.
    • timestamp_committed - the time the event was confirmed distributed to all DLT nodes in the value chain. Set by the system, cannot be changed by the client.

    Having these 3 fields enables users of DataTrails to accurately reflect what is claimed, whilst also preventing tampering and backdating of entries.

    User Principals on Events

    Just as with the “When”, the “Who” of “Who Did What When to an Asset" is potentially complicated if, for example, an application or gateway is acting on behalf of some other real-world user.

    Once committed to the DataTrails system, each lifecycle Event record carries 2 separate user identities:

    • principal_declared - an optional user-supplied value that tells who performed an Event. This is useful for cases where the user principal/credential used to authorize the Event does not accurately or usefully reflect the real-world agent (eg a multi-user application with device-based credentials).
    • principal_accepted - the actual user principal information belonging to the credential used to access the DataTrails REST interface. Set by the system and retrieved from the authorizing IDP, cannot be changed by the client.

    For more detailed information on Events and how to implement them, please refer to -the Events API Reference.

    Proof Mechanisms

    Assets and Events are core to the DataTrails platform, and being able to quickly demonstrate proof that these artifacts have not been tampered is key to being able to use them.

    When -creating an Asset, a proof mechanism will be used for that Asset and its Events. This determines how your data is recorded on the DataTrails blockchain.

    Simple Hash

    Simple Hash takes all the Events within a past time period (the default is the last 30 days) and commits them to the blockchain as one hash. This hash value can then be used to compare the current state of the Asset, and identify if any changes have occurred. With Simple Hash, you will not be able to see exactly what those changes were, only that something has changed.

    Note: The Simple Hash proof mechanism is available with -all tiers of the DataTrails platform.

    Access Policies

    Sharing the right amount of information with your value chain partners is critical to creating a trustworthy shared history for Assets. It is important that every participant be able to see and contribute to the management of Assets without compromising security, commercial, or private personal information. For example, competing vendors should not see each other’s information, but both should be able to freely collaborate with their mutual customer or industry regulator.

    In other scenarios, it is desirable to share basic maintenance information with a vendor or external maintenance company, whilst restricting critical operating information such as run cycles and cyber SLAs to a much smaller group.

    DataTrails Access Policies are the method through which this access is defined, allowing Asset owners to collaborate with just the right partners at the right time, sharing as much or as little access to Assets as the needs of the value chain partners dictate. All transactions are private by default, meaning that only the Asset owner can see and update Asset histories until a sharing policy has been set up. This ensures ready compliance with important regimes such as GDPR and antitrust regulations, as well as allowing safe and ready collaboration with a large and diverse range of value chain partners in the DataTrails network when required.

    Note: To collaborate with a value chain partner you first need to enroll them as a partner in your DataTrails Tenancy by exchanging your public DataTrails Subject Identity with each other, a little like making a new LinkedIn connection or Facebook friend.

    This one-time manual process helps to underpin trust and security in your DataTrails Access Policies by ensuring that the partners represented in them are the ones you expect.

    Considerations

    As with any system handling large amounts of important data, one must carefully consider the design and scope of Access Policy rules in DataTrails. -Every situation is different, and the DataTrails Access Policy system is flexible and powerful enough to support most situations, but in general it is recommended to follow some basic rules:

    • Aim for fewest possible number of policies: This makes it much easier to review and manage access rights.
    • Balance complex, highly-specific policies with simple, broad ones: Remember rights granted by policy are additive.
    • A single Access Policy can contain several permission groups, so it is possible to define a single filter to cover a particular population of Assets, then apply different rights to different sets of users and partner organizations. This is often a simpler way to manage access than to create separate Access Policies for each set of users.
    • Remember attributes can change: ABAC policies are applied at time of access request, not at time of creation, so changing attributes on an asset may change which access policies apply to it. This is one of the primary advantages to an ABAC system, but needs to be kept in mind when designing access control processes.

    Access Policy configuration

    DataTrails employs a principle called Attribute-Based Access Control (ABAC) for users within an organization, and a related concept called Organization-Based Access Control (OBAC) to mediate data sharing between value chain participants.

    Rather than applying a specific fixed policy to each Asset, or grouping them into rigid hierarchies, Access Policies are defined in terms of the observable properties (or attributes) of Assets and users, and if both match, the policy is applied. This enables much greater flexibility and expressivity than traditional hierarchical or role-based methods, whilst at the same time reducing complexity in defining sharing in large-scale systems.

    DataTrails Access Policies comprise of 2 main parts:

    • Filters: A list of attributes to match on Assets (this defines the scope of the policy)
    • Access Permissions: A list of access rights to be granted to users on those matching Assets

    A simple Access Policy may look like this:

    
+
    Note: The Asset Identity is fixed and constant for the life of the Asset and across all stakeholders. This ensures easy traceability and assurance that all stakeholders are collaborating on the same object and see the same complete history of Events.

    Deleting Assets (untracking)

    An essential value of storing evidence in DataTrails is that data is always available to stakeholders and cannot be shredded or manipulated later. Given this, it is not possible to actually delete Assets from the system, but there will be cases where it is desirable to hide Assets in the UI or omit them from default searches or compliance queries (for instance as a result of decommissioning or disposal of the corresponding physical asset).

    To accommodate this need DataTrails separates the Asset estate into 2 classes: tracked Assets (those that are interesting to the system and actively recording events) and untracked Assets (those that are no longer actively interesting). When for any reason it becomes desirable to remove an Asset, the Asset owner can make it untracked so that it does not appear in lists or searches.

    Caution: Untracking an Asset does not remove it or its Event history from the system; all stakeholders who previously had access to the record will continue to have access to the Event history, including the untracking event, if they look for it.

    Timestamps on Events

    Lifecycle events in DataTrails give stakeholders a shared view of “Who did What When to an Asset". The “What” and the “Asset” are quite straightforward, but the “When” and “Who” can be more nuanced.

    Once committed to the DataTrails system, each lifecycle Event record carries 3 separate timestamps:

    • timestamp_declared - an optional user-supplied value that tells when an Event happened. This is useful for cases where the client system is off-line for a period but the user still wishes to record the accurate time and order of activities (eg inspection rounds in an air-gapped facility). If unspecified, the system sets timestamp_declared equal to timestamp_accepted (see below).
    • timestamp_accepted - the time the event was actually received on the DataTrails REST interface. Set by the system, cannot be changed by the client.
    • timestamp_committed - the time the event was confirmed distributed to all DLT nodes in the value chain. Set by the system, cannot be changed by the client.

    Having these 3 fields enables users of DataTrails to accurately reflect what is claimed, whilst also preventing tampering and backdating of entries.

    User Principals on Events

    Just as with the “When”, the “Who” of “Who Did What When to an Asset" is potentially complicated if, for example, an application or gateway is acting on behalf of some other real-world user.

    Once committed to the DataTrails system, each lifecycle Event record carries 2 separate user identities:

    • principal_declared - an optional user-supplied value that tells who performed an Event. This is useful for cases where the user principal/credential used to authorize the Event does not accurately or usefully reflect the real-world agent (eg a multi-user application with device-based credentials).
    • principal_accepted - the actual user principal information belonging to the credential used to access the DataTrails REST interface. Set by the system and retrieved from the authorizing IDP, cannot be changed by the client.

    For more detailed information on Events, and how to implement them, please refer to the +Events API Reference.

    Proof Mechanisms

    Assets and Events are core to the DataTrails platform, and being able to quickly demonstrate proof that these artifacts have not been tampered is key to being able to use them.

    When +creating an Asset, DataTrails uses a proof mechanism for that Asset and its Events. This determines how your data is recorded on the DataTrails blockchain.

    Our Simple Hash proof mechanism takes all the Events within a past time period (the default is the last 30 days) and commits them to the blockchain as one hash. This hash value can then be used to compare the current state of the Asset, and identify if any changes have occurred. With Simple Hash, you will not be able to see exactly what those changes were, only that something has changed.

    Access Policies

    Sharing the right amount of information with your value chain partners is critical to creating a trustworthy shared history for Assets. It is important that every participant be able to see and contribute to the management of Assets without compromising security, commercial, or private personal information. For example, competing vendors should not see each other’s information, but both should be able to freely collaborate with their mutual customer or industry regulator.

    In other scenarios, it is desirable to share basic maintenance information with a vendor or external maintenance company, whilst restricting critical operating information such as run cycles and cyber SLAs to a much smaller group.

    DataTrails Access Policies are the method through which this access is defined, allowing Asset owners to collaborate with just the right partners at the right time, sharing as much or as little access to Assets as the needs of the value chain partners dictate. All transactions are private by default, meaning that only the Asset owner can see and update Asset histories until a sharing policy has been set up. This ensures ready compliance with important regimes such as GDPR and antitrust regulations, as well as allowing safe and ready collaboration with a large and diverse range of value chain partners in the DataTrails network when required.

    Note: To collaborate with a value chain partner you first need to enroll them as a partner in your DataTrails Tenancy by exchanging your public DataTrails Subject Identity with each other, a little like making a new LinkedIn connection or Facebook friend.

    This one-time manual process helps to underpin trust and security in your DataTrails Access Policies by ensuring that the partners represented in them are the ones you expect.

    Public Attestations

    While a strict, 1-to-1 relationship might be desirable for some use cases, it is also possible that a recorded asset and associated events are recorded in a more widely accessible way. With the use of our Public setting for an asset, you can create an access policy which enables anyone to view that asset record. A viewer of that asset does not have to be registered with DataTrails, and can anonymously use our +Instaproof service to check the thing they have against the public record in DataTrails.

    Note: Instaproof uses the hash of a file, piece of data or digital artifact to check for associated records with that hash value. This enables users to quickly check if the thing they have is the correct, unaltered version they are expecting.

    Considerations

    As with any system handling large amounts of important data, one must carefully consider the design and scope of Access Policy rules in DataTrails. +Every situation is different, and the DataTrails Access Policy system is flexible and powerful enough to support most situations, but in general it is recommended to follow some basic rules:

    • Aim for fewest possible number of policies: This makes it much easier to review and manage access rights.
    • Balance complex, highly-specific policies with simple, broad ones: Remember rights granted by policy are additive.
    • A single Access Policy can contain several permission groups, so it is possible to define a single filter to cover a particular population of Assets, then apply different rights to different sets of users and partner organizations. This is often a simpler way to manage access than to create separate Access Policies for each set of users.
    • Remember attributes can change: ABAC policies are applied at time of access request, not at time of creation, so changing attributes on an asset may change which access policies apply to it. This is one of the primary advantages to an ABAC system, but needs to be kept in mind when designing access control processes.

    Access Policy configuration

    DataTrails employs a principle called Attribute-Based Access Control (ABAC) for users within an organization who are given +internal access to your tenant. A related concept called Organization-Based Access Control (OBAC) is provided to mediate data sharing between value chain participants who will share +external access to their tenants.

    Rather than applying a specific fixed policy to each Asset, or grouping them into rigid hierarchies, Access Policies are defined in terms of the observable properties (or attributes) of Assets and users, and if both match, the policy is applied. This enables much greater flexibility and expressivity than traditional hierarchical or role-based methods, whilst at the same time reducing complexity in defining sharing in large-scale systems.

    DataTrails Access Policies comprise of 2 main parts:

    • Filters: A list of attributes to match on Assets (this defines the scope of the policy)
    • Access Permissions: A list of access rights to be granted to users on those matching Assets

    A simple Access Policy may look like this:

    
     {
       // identity and tenant are non-modifiable system info
       "identity": "access_policies/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
@@ -137,10 +138,10 @@
   { "or": [vendor=SynsationIndustries] },
   { "or": [location=ChicagoWest,location=ChicagoEast] }
 ]
-

    In the above simplified example, the policy would apply to any Pump or Valve from SynsationIndustries installed in either the ChicagoWest or ChicagoEast sites, but it would not match:

    • Other device types from SynsationIndustries;
    • Pumps or Valves from any other vendor;
    • SynsationIndustries Valves installed in a different location

    Revoking Access

    DataTrails adopts a ‘default deny’ approach so access to an Asset Record is only possible if an Access Policy explicitly allows it.

    Revoking access can therefore be achieved in a number of ways, any of which may be more or less appropriate for the circumstances:

    • Remove the whole Access Policy
    • Change the attributes of the Asset so that it no longer matches the Access Policy (eg change location)
    • Change the attributes of the user or subject so that they no longer match the Access Policy (eg change IDP group)
    • Turn off the user’s login at the IDP
    Note: As with any fair decentralized system it is not possible to ‘unsee’ information. Any change in OBAC access policies including revoking OBAC access to a value chain partner only applies to new information contributed after the policy change. This ensures continued fair access to the historic evidence base for all legitimate participants whilst also maintaining control of future operations with the Asset owner.

    Attachments and Blobs

    Attachments in DataTrails enable images, PDFs and other binary data to be attached to Assets and Events. This brings added richness to the evidence base and facilitates high fidelity collaboration between stakeholders.

    Adding an attachment to an Asset or Event enables recording of characteristics or evidence that are very difficult to capture in the rigid structured JSON data of Attributes. For example:

    • a photograph of the physical state of a device such as alignment of components or wear on tamper seals at the time of a particular inspection
    • a PDF of a safety conformance report to support a maintenance event
    • a software manifest to support an update
    • an x-ray image

    Attaching rich evidence to an Asset or Event is a two step process:

    1. First a Binary Large OBject (BLOB) is uploaded
    2. Then a reference to that blob is attached to the Event or Asset.

    To add attachments to an Event, simply specify an attribute in the event_attributes of the POST request with a dictionary including the blob information and with "arc_attribute_type": "arc_attachment". To add or update an attachment on an Asset, put the attachment attribute in the asset_attributes of the request instead.

    For more detailed information on Attachments and how to implement them, please refer to +

    In the above simplified example, the policy would apply to any Pump or Valve from SynsationIndustries installed in either the ChicagoWest or ChicagoEast sites, but it would not match:

    • Other device types from SynsationIndustries;
    • Pumps or Valves from any other vendor;
    • SynsationIndustries Valves installed in a different location

    Revoking Access

    DataTrails adopts a ‘default deny’ approach so access to an Asset Record is only possible if an Access Policy explicitly allows it.

    Revoking access can therefore be achieved in a number of ways, any of which may be more or less appropriate for the circumstances:

    • Remove the whole Access Policy
    • Change the attributes of the Asset so that it no longer matches the Access Policy (eg change location)
    • Change the attributes of the user or subject so that they no longer match the Access Policy (eg change IDP group)
    • Turn off the user’s login at the IDP
    Note: As with any fair decentralized system it is not possible to ‘unsee’ information. Any change in OBAC access policies including revoking OBAC access to a value chain partner only applies to new information contributed after the policy change. This ensures continued fair access to the historic evidence base for all legitimate participants whilst also maintaining control of future operations with the Asset owner.

    Attachments and Blobs

    Note: DataTrails intends to be a store of metadata for your data that is independent of that data, allowing you to continue to work in the places where you already work. Where it is possible, DataTrails recommends keeping your data in the places that it is already kept, rather than creating a duplicate copy in your ledger.

    Attachments in DataTrails enable images, PDFs and other binary data to be attached to Assets and Events. This brings added richness to the evidence base and facilitates high fidelity collaboration between stakeholders.

    Adding an attachment to an Asset or Event enables recording of characteristics or evidence that are very difficult to capture in the rigid structured JSON data of Attributes. For example:

    • a photograph of the physical state of a device such as alignment of components or wear on tamper seals at the time of a particular inspection
    • a PDF of a safety conformance report to support a maintenance event
    • a software manifest to support an update
    • an x-ray image

    Attaching rich evidence to an Asset or Event is a two step process:

    1. First a Binary Large OBject (BLOB) is uploaded
    2. Then a reference to that blob is attached to the Event or Asset.

    To add attachments to an Event, simply specify an attribute in the event_attributes of the POST request with a dictionary including the blob information and with "arc_attribute_type": "arc_attachment". To add or update an attachment on an Asset, put the attachment attribute in the asset_attributes of the request instead.

    For more detailed information on Attachments and how to implement them, please refer to the Blobs API Reference and the Attachments API Reference

    The Primary Image

    Attachments on Assets are named in their arc_display_name property, so that they can be searched and indexed. Names are arbitrary and may be defined according to the needs of the application, but one name is reserved and interpreted by the DataTrails services: arc_primary_image. -If an asset has an attachment attribute named arc_primary_image, then this will be used by the SaaS user interface and other tools to represent the asset.

    Note: Blobs and Attachments cannot be searched or listed as a collection in their own right: they must always be associated with an Asset or Event through an Attachment Attribute and can only be downloaded by users with appropriate access rights to that Attachment.
    Note: While Attachments are generally expected to be unique, the same attachment can be applied to multiple assets, such as the case of a process manual PDF.

    Geolocation

    DataTrails supports 2 different main concepts of geolocation, and it’s important to choose the correct one for your use case.

    • Locations on Assets, which enable grouping of Assets based on some common management (“All these devices live in the Basingstoke factory”)
    • GIS coordinates on Events, which enable recording of exactly where an event took place, and when analyzed together can show the movement of an Asset (“This was scanned in London, and later sold in Manchester”)

    Essentially Locations give you groupings:

    Grouping Assets by location

    Whereas Event coordinates give you tracking:

    Tracking Assets with GIS coordinates

    Asset Locations

    Caution: It is important to recognize that the location does not necessarily denote the Asset’s current position in space; it simply determines which facility the Asset belongs to. For things that move around, use GIS coordinates on Events instead.

    Assets in DataTrails can be arranged into locations, which allows virtual assets (eg digital twins) to be grouped together in a physical context (eg a single plant location). Locations have full 6-digit decimal latitude and longitude components along with full address details allowing high-precision placement on any map renderer or GIS software you wish to link them to. It is not required for assets to be associated with a location, but it is a useful way to group assets in the same physical location and provides for numerous convenience functions in the DataTrails UI.

    This enables users of the system to quickly identify the answers to questions such as “how many PLCs in the Greyslake plant need to be updated?”, or “who was the last person to touch any device in the Cape Town facility?”. Locations support custom attributes which can be defined and used for any purpose by the user. This enables storage of a mailing address, phone number, or contact details of the site manager, for example.

    Locations are editable and deletable as much as you want. Their references are stored on the DLT but the actual objects are not.

    Note: If your use case does not concern physical sites like factory plant locations or offices it is still possible to use locations to logically group related Assets together. However, in this instance it is likely to be more scalable to use a custom attribute to link Assets.

    GIS Coordinates on Events

    If you’re wanting to track the movement of an Asset, or record an audit trail of where a particular Event happens, you can add arc_gis_lat and arc_gis_lng attributes to the event_attributes.

    For example:

        {
+If an asset has an attachment attribute named arc_primary_image, then this will be used by the SaaS user interface and other tools to represent the asset.
     Note: Blobs and Attachments cannot be searched or listed as a collection in their own right: they must always be associated with an Asset or Event through an Attachment Attribute and can only be downloaded by users with appropriate access rights to that Attachment.
     Note: While Attachments are generally expected to be unique, the same attachment can be applied to multiple assets, such as the case of a process manual PDF.
    Geolocation
    DataTrails supports 2 different main concepts of geolocation, and it’s important to choose the correct one for your use case.
    • Locations on Assets, which enable grouping of Assets based on some common management (“All these devices live in the Basingstoke factory”)
    • GIS coordinates on Events, which enable recording of exactly where an event took place, and when analyzed together can show the movement of an Asset (“This was scanned in London, and later sold in Manchester”)
    Essentially Locations give you groupings:
    Grouping Assets by location
    Whereas Event coordinates give you tracking:
    Tracking Assets with GIS coordinates
    Asset Locations
     Caution: It is important to recognize that the location does not necessarily denote the Asset’s current position in space; it simply determines which facility the Asset belongs to. For things that move around, use GIS coordinates on Events instead.
    Assets in DataTrails can be arranged into locations, which allows virtual assets (eg digital twins) to be grouped together in a physical context (eg a single plant location). Locations have full 6-digit decimal latitude and longitude components along with full address details allowing high-precision placement on any map renderer or GIS software you wish to link them to. It is not required for assets to be associated with a location, but it is a useful way to group assets in the same physical location and provides for numerous convenience functions in the DataTrails UI.
    This enables users of the system to quickly identify the answers to questions such as “how many PLCs in the Greyslake plant need to be updated?”, or “who was the last person to touch any device in the Cape Town facility?”. Locations support custom attributes which can be defined and used for any purpose by the user. This enables storage of a mailing address, phone number, or contact details of the site manager, for example.
    Locations are editable and deletable as much as you want. Their references are stored on the DLT but the actual objects are not.
     Note: If your use case does not concern physical sites like factory plant locations or offices it is still possible to use locations to logically group related Assets together. However, in this instance it is likely to be better and more scalable to use your own custom attribute to link Assets.
    GIS Coordinates on Events
    If you’re wanting to track the movement of an Asset, or record an audit trail of where a particular Event happens, you can add arc_gis_lat and arc_gis_lng attributes to the event_attributes.
    For example:
        {
       "asset_identity": "assets/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
       "behaviour": "RecordEvidence",
       "operation": "Record",
@@ -151,7 +152,7 @@
         "arc_gis_lng" : "-122.429286"
       }
     }
-
    Once applied the GIS coordinates on Events are immutable.
    Compliance Policies
    Trust is subjective. Compliance is a judgement call. No matter what security technology you have in play, every trust decision you make will depend on the circumstances: who is accessing what; where they’re coming from; how sensitive an operation they’re attempting; the consequences of getting it wrong. An Asset that is safe in one context may not be in another.
    By maintaining a complete traceable record of Who Did What When to a Thing, DataTrails makes it possible for any authorized stakeholder to quickly and easily verify that critical processes have been followed and recorded correctly. And if they weren’t, the record makes it easy to discover where things went wrong and what to fix. For instance, missed or late maintenance rounds can be detected simply by spotting gaps in the maintenance record; cyber vulnerable devices can be found by comparing ideal baselines with patching records; out-of-order process execution and handling violations are visible to all; and back-dating is automatically detectable.
    All of this is very valuable in audit and RCA situations after an incident, where there is time to collect together Asset records, piece together the important parts, and analyze the meaning.
    But what if the same information could be used for real-time decision-making that might avert an incident? This is where DataTrails’ “compliance posture” APIs come in. These take the thinking and processing burden off the client by providing a single, simple API call to answer the complex question: “given all you know about this asset, should I trust it right now?”. Additionally, and crucially for sensitive use cases, the yes or no answer comes with a detailed defensible reason why which can be inspected by relevant stakeholders during or after the event.
    When put all together, this enables high quality decision making based on the best available data, even giving confidence to automated or AI systems to play a full part in operations. Assets can be checked as part of access control logic, prior to accepting data or commands from them, accepting a shipment, or anything else that is important to your business. Crucially, each stakeholder is able to define their own view on Compliance, meaning they can each apply their own unique lens and business concerns to the same evidence base.
    Compliance Policy Configuration
    In order to make these trust decisions, DataTrails can be configured with Compliance Policies to check Assets against. These policies specify things like tolerance for vulnerability windows, maintenance SLAs, or detecting unusual values for attributes. For example:
    • “Assets must be patched within 40 days of vulnerability notification”
    • “Maintenance calls must be answered within 72 hours”
    • “rad level must be less than 7”
    Policies can also declare relative tolerances, such as:
    • “No shipping transfer should be more than 10% longer than the average time”
    • “The reported weight of this container should be within 1 standard deviation of the historic mean”
    Individual assets either pass or fail, and organizations can calculate their overall security/compliance posture based on what proportion of their assets are breaching their policy set. Compliance signals can also be used to identify where risk lies in an organization and help to prioritize remedial activities.
    Types of Compliance Policy
    As with Assets and Events, Compliance Policies are very flexible and can be configured to answer a wide range of business problems. The following categories of policy are supported:
    • COMPLIANCE RICHNESS: This Compliance Policy checks whether a specific attribute of an Asset is within acceptable bounds.
      For example, “Weight attribute must be less than 1000 kg”
    • COMPLIANCE SINCE: This Compliance Policy checks if the time since the last occurrence of a specific Event Type has elapsed a specified threshold.
      For example, “Time since last Maintenance must be less than 72 hours”
    • COMPLIANCE CURRENT OUTSTANDING: This Compliance Policy will only pass if there is an associated closing event addressing a specified outstanding event.
      For example, checking there are no outstanding “Maintenance Request” Events that are not addressed by an associated “Maintenance Performed” Event.
    • COMPLIANCE_PERIOD_OUTSTANDING: This Compliance Policy will only pass if the time between a pair of correlated events did not exceed the defined threshold.
      For example, a policy checking that the time between “Maintenance Request” and “Maintenance Performed” Events does not exceed the maximum 72 hours.
    • COMPLIANCE_DYNAMIC_TOLERANCE: This Compliance Policy will only pass if the time between a pair of correlated events or the value of an attribute does not exceed the a variability from the usually observed values.
      For example, a policy checking that maintenance times are not considerably longer than normal, or the weight of a container is not much less than the typical average.
     Note: To correlate Events, define the attribute arc_correlation_value in the Event attributes and set it to the same value on each pair of Events that are to be associated.
    Perspectives
    In the Asset example above there is an at_time property, which reflects a date and time at which these attributes and values were contemporary. Usually this will just be the current system time, but with DataTrails it is possible to go back in time and ask the question “what would that asset have looked like to me had I looked at it last week/last year/before the incident?”. Using its high integrity record of Asset lineage, DataTrails can give clear and faithful answers to those questions with no fear of backdating, forgery, or repudiation getting in the way.
    To do this, simply add at_time=TIMESTAMP to your query. For example, to check the state an Asset was in at 15:30 UTC on 23rd June:
    curl -H "Authorization: Bearer $(cat .auth_token)" -H "Content-Type: application/json" https://app.datatrails.ai/archivist/v2/assets/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx?at_time=2021-06-23T15:30:00Z | jq 
+
    Once applied the GIS coordinates on Events are immutable.
    Compliance Policies
     Note: Creation and editing of Compliance Policies is only supported through the API.
    Trust is subjective. Compliance is a judgement call. No matter what security technology you have in play, every trust decision you make will depend on the circumstances: who is accessing what; where they’re coming from; how sensitive an operation they’re attempting; the consequences of getting it wrong. An Asset that is safe in one context may not be in another.
    By maintaining a complete traceable record of Who Did What When to a Thing, DataTrails makes it possible for any authorized stakeholder to quickly and easily verify that critical processes have been followed and recorded correctly. And if they weren’t, the record makes it easy to discover where things went wrong and what to fix. For instance, missed or late maintenance rounds can be detected simply by spotting gaps in the maintenance record; cyber vulnerable devices can be found by comparing ideal baselines with patching records; out-of-order process execution and handling violations are visible to all; and back-dating is automatically detectable.
    All of this is very valuable in audit and RCA situations after an incident, where there is time to collect together Asset records, piece together the important parts, and analyze the meaning.
    But what if the same information could be used for real-time decision-making that might avert an incident? This is where DataTrails’ “compliance posture” APIs come in. These take the thinking and processing burden off the client by providing a single, simple API call to answer the complex question: “given all you know about this asset, should I trust it right now?”. Additionally, and crucially for sensitive use cases, the yes or no answer comes with a detailed defensible reason why which can be inspected by relevant stakeholders during or after the event.
    When put all together, this enables high quality decision making based on the best available data, even giving confidence to automated or AI systems to play a full part in operations. Assets can be checked as part of access control logic, prior to accepting data or commands from them, accepting a shipment, or anything else that is important to your business. Crucially, each stakeholder is able to define their own view on Compliance, meaning they can each apply their own unique lens and business concerns to the same evidence base.
    Compliance Policy Configuration
    In order to make these trust decisions, DataTrails can be configured with Compliance Policies to check Assets against. These policies specify things like tolerance for vulnerability windows, maintenance SLAs, or detecting unusual values for attributes. For example:
    • “Assets must be patched within 40 days of vulnerability notification”
    • “Maintenance calls must be answered within 72 hours”
    • “rad level must be less than 7”
    Policies can also declare relative tolerances, such as:
    • “No shipping transfer should be more than 10% longer than the average time”
    • “The reported weight of this container should be within 1 standard deviation of the historic mean”
    Individual assets either pass or fail, and organizations can calculate their overall security/compliance posture based on what proportion of their assets are breaching their policy set. Compliance signals can also be used to identify where risk lies in an organization and help to prioritize remedial activities.
    Types of Compliance Policy
    As with Assets and Events, Compliance Policies are very flexible and can be configured to answer a wide range of business problems. The following categories of policy are supported:
    • COMPLIANCE RICHNESS: This Compliance Policy checks whether a specific attribute of an Asset is within acceptable bounds.
      For example, “Weight attribute must be less than 1000 kg”
    • COMPLIANCE SINCE: This Compliance Policy checks if the time since the last occurrence of a specific Event Type has elapsed a specified threshold.
      For example, “Time since last Maintenance must be less than 72 hours”
    • COMPLIANCE CURRENT OUTSTANDING: This Compliance Policy will only pass if there is an associated closing event addressing a specified outstanding event.
      For example, checking there are no outstanding “Maintenance Request” Events that are not addressed by an associated “Maintenance Performed” Event.
    • COMPLIANCE_PERIOD_OUTSTANDING: This Compliance Policy will only pass if the time between a pair of correlated events did not exceed the defined threshold.
      For example, a policy checking that the time between “Maintenance Request” and “Maintenance Performed” Events does not exceed the maximum 72 hours.
    • COMPLIANCE_DYNAMIC_TOLERANCE: This Compliance Policy will only pass if the time between a pair of correlated events or the value of an attribute does not exceed the a variability from the usually observed values.
      For example, a policy checking that maintenance times are not considerably longer than normal, or the weight of a container is not much less than the typical average.
     Note: To correlate Events, define the attribute arc_correlation_value in the Event attributes and set it to the same value on each pair of Events that are to be associated.
    Perspectives
    In the Asset example above there is an at_time property, which reflects a date and time at which these attributes and values were contemporary. Usually this will just be the current system time, but with DataTrails it is possible to go back in time and ask the question “what would that asset have looked like to me had I looked at it last week/last year/before the incident?”. Using its high integrity record of Asset lineage, DataTrails can give clear and faithful answers to those questions with no fear of backdating, forgery, or repudiation getting in the way.
    To do this, simply add at_time=TIMESTAMP to your query. For example, to check the state an Asset was in at 15:30 UTC on 23rd June:
    curl -H "Authorization: Bearer $(cat .auth_token)" -H "Content-Type: application/json" https://app.datatrails.ai/archivist/v2/assets/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx?at_time=2021-06-23T15:30:00Z | jq 
 
    Compliance calls can be similarly modified to answer questions like “had I asked this question at the time, what would the answer have been?” or “had the AI asked this question, would it have made a better decision?”. This can be done by adding a compliant_at timestamp to the compliance request.
    That’s it
    These are all the basics of DataTrails. With this knowledge you can now
-jump straight into the API or try other topic on the
-DataTrails Platform.
    ← Core Concepts
    Creating an Asset →
    \ No newline at end of file +jump straight into the API or try other topics on the +DataTrails Platform.

    ← Core Concepts
    Creating an Asset →
    \ No newline at end of file diff --git a/platform/overview/core-concepts/index.html b/platform/overview/core-concepts/index.html index 5ebec6e5f..c4a32abf5 100644 --- a/platform/overview/core-concepts/index.html +++ b/platform/overview/core-concepts/index.html @@ -19,4 +19,4 @@ Public View which is visible to everyone. The purpose of this view is to allow anyone to verify that the document that they are using is genuine and has not been altered. When the document Audit Trail is combined with Instaproof a user of your data can easily find out which version of a document they have and confirm that it is genuine.

    The Golden Thread

    Using the four concepts of Tenancy, Assets, Events and Access Policies it is possible to create a Golden Thread of evidence makes up the Data Trails Audit Trail. -This has many use cases relating to content authenticity but can also be applied to supply chain integrity and standards compliance, or fact anything where stakeholders need transparency and trust.

    The Golden Thread

    ← Introduction
    Advanced Concepts →
    \ No newline at end of file +This has many use cases relating to content authenticity but can also be applied to supply chain integrity and standards compliance, or fact anything where stakeholders need transparency and trust.

    The Golden Thread

    ← Introduction
    Advanced Concepts →
    \ No newline at end of file diff --git a/platform/overview/creating-an-asset/index.html b/platform/overview/creating-an-asset/index.html index fc3d74870..10e361512 100644 --- a/platform/overview/creating-an-asset/index.html +++ b/platform/overview/creating-an-asset/index.html @@ -162,4 +162,4 @@ -H "@$HOME/.datatrails/bearer-token.txt" \ https://app.datatrails.ai/archivist/v2/assets?attributes.arc_display_name=My%20First%20Container     Here we see all details entered: The extended attributes and a history of Events recorded on the Asset.

    Note: After registration, Assets cannot be updated using the asset creation screens but an Asset’s Asset Attributes can be updated as part of an Event.

    For more information on creating Events, -click here.

    The first Event will always be the Asset Creation. In the next section, we will cover how to create your own Events for your Asset.

    ← Advanced Concepts
    Creating an Event Against an Asset →
    \ No newline at end of file +click here.

    The first Event will always be the Asset Creation. In the next section, we will cover how to create your own Events for your Asset.

    ← Advanced Concepts
    Creating an Event Against an Asset →
    \ No newline at end of file diff --git a/platform/overview/creating-an-event-against-an-asset/index.html b/platform/overview/creating-an-event-against-an-asset/index.html index 5c2fdb5e3..9b9885fca 100644 --- a/platform/overview/creating-an-event-against-an-asset/index.html +++ b/platform/overview/creating-an-event-against-an-asset/index.html @@ -153,4 +153,4 @@ -H "@$HOME/.datatrails/bearer-token.txt" \ https://app.datatrails.ai/archivist/v2/assets/<asset-id>/events/<event-id> Please see the -Administration section for information on how to manage your assets

    In the next section we look at a specific type of Asset, the Document Profile Asset.

    ← Creating an Asset
    Registering a Document Profile Asset →
    \ No newline at end of file +Administration section for information on how to manage your assets

    In the next section we look at a specific type of Asset, the Document Profile Asset.

    ← Creating an Asset
    Registering a Document Profile Asset →
    \ No newline at end of file diff --git a/platform/overview/index.html b/platform/overview/index.html index 039654568..fe38a7ef2 100644 --- a/platform/overview/index.html +++ b/platform/overview/index.html @@ -5,4 +5,4 @@
    \ No newline at end of file +Sign Up
    \ No newline at end of file diff --git a/platform/overview/index.xml b/platform/overview/index.xml index 3f5b3887d..4c2d2a4fd 100644 --- a/platform/overview/index.xml +++ b/platform/overview/index.xml @@ -1,6 +1,6 @@ -Overview onhttps://docs.datatrails.ai/platform/overview/Recent content in Overview onHugo -- gohugo.ioen-GBWed, 26 Jul 2023 13:07:55 +0100Introductionhttps://docs.datatrails.ai/platform/overview/introduction/Mon, 14 Jun 2021 10:57:58 +0100https://docs.datatrails.ai/platform/overview/introduction/DataTrails provides Provenance as a Service that continuously proves Who Did What When to all data types. -DataTrails enables enterprises to build trust in data such as documents, images and sound files by ensuring that you know the origin and history of the data that you are using. This can also be applied to multi-party Assets such as software and physical items allowing you to make sure that processes are fit for purpose to comply with IT controls, corporate policies, and government regulations.Core Conceptshttps://docs.datatrails.ai/platform/overview/core-concepts/Mon, 14 Jun 2021 10:57:58 +0100https://docs.datatrails.ai/platform/overview/core-concepts/Tenancies A Tenancy is an Organization&rsquo;s private area within DataTrails, containing Asset and Event data that build over time to create an Audit Trail. The user who created the Tenancy is the Administrator and has full administrative control over everything in that Tenancy. An Administrator can also create granular Access Policies which allow data from their Tenancy to be shared to other Tenancies; for example, Organization A would share Asset data from their Tenancy to Organization B&rsquo;s Tenancy.Advanced Conceptshttps://docs.datatrails.ai/platform/overview/advanced-concepts/Mon, 14 Jun 2021 10:57:58 +0100https://docs.datatrails.ai/platform/overview/advanced-concepts/Assets Central to all DataTrails operations are Assets. These are the records that represent the collective &lsquo;Golden Thread&rsquo; of evidence contributed by all stakeholders about a particular thing. Assets can represent anything: a physical object, a smart device, or even a business process. As long as shared accountability needs to be traced and trustworthy, it can be recorded as a DataTrails Asset. -DataTrails Assets are essentially very simple: a collection of attributes that describe the Asset expressed as a standard JSON document.Creating an Assethttps://docs.datatrails.ai/platform/overview/creating-an-asset/Tue, 18 May 2021 14:52:25 +0100https://docs.datatrails.ai/platform/overview/creating-an-asset/An Asset can be anything: a file (a document, an image, a sound file etc.), a software application, a shipping container, or even a physical product. It can be any digital or physical object with an associated name, description, and attributes. +Overview onhttps://docs.datatrails.ai/platform/overview/Recent content in Overview onHugo -- gohugo.ioen-GBTue, 19 Mar 2024 10:57:58 +0100Introductionhttps://docs.datatrails.ai/platform/overview/introduction/Mon, 14 Jun 2021 10:57:58 +0100https://docs.datatrails.ai/platform/overview/introduction/DataTrails provides Provenance as a Service that continuously proves Who Did What When to all data types. +DataTrails enables enterprises to build trust in data such as documents, images and sound files by ensuring that you know the origin and history of the data that you are using. This can also be applied to multi-party Assets such as software and physical items allowing you to make sure that processes are fit for purpose to comply with IT controls, corporate policies, and government regulations.Core Conceptshttps://docs.datatrails.ai/platform/overview/core-concepts/Mon, 14 Jun 2021 10:57:58 +0100https://docs.datatrails.ai/platform/overview/core-concepts/Tenancies A Tenancy is an Organization&rsquo;s private area within DataTrails, containing Asset and Event data that build over time to create an Audit Trail. The user who created the Tenancy is the Administrator and has full administrative control over everything in that Tenancy. An Administrator can also create granular Access Policies which allow data from their Tenancy to be shared to other Tenancies; for example, Organization A would share Asset data from their Tenancy to Organization B&rsquo;s Tenancy.Advanced Conceptshttps://docs.datatrails.ai/platform/overview/advanced-concepts/Mon, 14 Jun 2021 10:57:58 +0100https://docs.datatrails.ai/platform/overview/advanced-concepts/Assets and Events The core tenets of the DataTrails platform are Assets and Events. These are the records that represent the collective &lsquo;Golden Thread&rsquo; of evidence contributed by all stakeholders about a particular thing. +Assets can represent anything: a file, a piece of data, a physical thing or even a business process. As long as shared accountability needs to be traced and trustworthy, it can be recorded as a DataTrails Asset.Creating an Assethttps://docs.datatrails.ai/platform/overview/creating-an-asset/Tue, 18 May 2021 14:52:25 +0100https://docs.datatrails.ai/platform/overview/creating-an-asset/An Asset can be anything: a file (a document, an image, a sound file etc.), a software application, a shipping container, or even a physical product. It can be any digital or physical object with an associated name, description, and attributes. Each Asset will have a history of any actions performed upon it by any actor. You may share Assets and their history with specific stakeholders using permission sharing. DataTrails also enables you to publicly attest the provenance of your Assets.Creating an Event Against an Assethttps://docs.datatrails.ai/platform/overview/creating-an-event-against-an-asset/Tue, 18 May 2021 15:32:01 +0100https://docs.datatrails.ai/platform/overview/creating-an-event-against-an-asset/If you wish to begin tracking your Asset history and build an immutable Audit Trail, you need to create Events. Asset Creation is the first Event. The more Events recorded against an Asset, the richer and deeper its history becomes. diff --git a/platform/overview/instaproof/index.html b/platform/overview/instaproof/index.html index 2fe0ae28f..8a1c90594 100644 --- a/platform/overview/instaproof/index.html +++ b/platform/overview/instaproof/index.html @@ -12,4 +12,4 @@ Document Profile more more information.

    Using the Instaproof UI

    1. Using the sidebar, select Instaproofand then drag a document into the search area

      Instaproof Search Area

    2. Document not found
      If the document that you are verifying has not been found, you will see a red response banner.

      Document Not Found
      The possible reasons for this outcome are:

      • The document owner has not registered the document in their DataTrails tenancy
      • The document owner has not published this version of the document as an event
      • The document has been modified since it was registered with DataTrails


      In all cases you should contact the document owner to find out whether your document version can be trusted.

    3. Document Found

      Note: In this screenshot we are using the file greenfrog.jpg which can be downloaded from our Instaproof Samples page.
      If the document has been registered with DataTrails, you will see a green response banner together with a list of all the matching Document Profile Assets. This means that the version of the document that you have has a verifiable provenance record and an immutable audit trail.
      Document Found

    At the top of the image you can see the document that was checked and found on Instaproof.

    Note: We don’t need to access your document to find its provenance, everything that you see in the Instaproof results is held locally and was recorded by the document owner when the document was registered or events were recorded.

    You can check additional documents by dragging them on top of this area.

    Some of the results may be from verified organizations and others from unverified members of the DataTrails community. All results contribute something to the provenance and life history of this document.

    A Verified Organization has a verified domain associated with their DataTrails account. This helps to confirm the identity of the document source and is likely the thing to look for if you want ‘official’ provenance records. A Verified Domain can be used to link an identity (such as a company or a brand name) to a DataTrails Tenancy.

    The Other Results results are those from from unverified DataTrails accounts - other members of the DataTrails community who have made claims or observations about the document you’re interested in.

    While they may seem less ‘official’ than verified account results, they may still be useful to you. The identity of all users making attestations in DataTrails is checked, recorded, and immutable, even if they are not (yet) associated with a verified domain name.

    What Do the Instaproof Results Mean

    Immutable Audit Trail

    Click on a result to see details of the document history. You will see the Event details of the version that matches your document on the right with a partial view of the Asset details for the latest version on the left. Close the Event details to see the full Asset details view.

    Asset Details Tab

    The Asset details tab shows the information about the asset attributes. -Includes the current version, the organization, and Verified Domain badge, if applicable.

    Public attestation and visibility - Public means that the document is publicly accessible using the public URL. Permissioned means that it is private and requires shared access to be enabled for a user to be able to view it.

    Type - For Document Profile Assets this will always be ‘Document’.

    Description - an optional description of the Asset

    Attributes - This drop down section contains any custom attributes that were added to the asset.

    Versions - the published versions of the document

    Note: The share button allows you to access and copy the permissioned and public (if enabled) links for the asset to share with other users. Private links are for logged in users with permissions assigned in an Access Policy, Public links are for everyone.
    Share Links

    The Event History tab shows the full history of Events including custom Events, new Versions and Withdraw Events.

    Click on the tab and select an Event to view the details.

    Event History Overview Tab

    The Overview information about the Event

    Event Identity - The Event ID will always be of the format ‘publicassets/<asset_id>/events/<event_id>’ for public assets or ‘assets/<asset_id>/events/<event_id>’ for private assets.

    Asset Identity - the ID of the parent Asset for this Event.

    Transaction - This link contains the details of the blockchain transaction.

    Transaction Details

    Type - For Document Profile Events this will always be ‘Publish’

    Document changes - The version and document hash for new version Events. There is no data here for custom Events.

    The Event attributes and Asset attributes tabs contain information about any custom attributes that were added or modified as part this Event.

    ← Registering an Event Against a Document Profile Asset
    Public Attestation →
    \ No newline at end of file +Includes the current version, the organization, and Verified Domain badge, if applicable.

    Public attestation and visibility - Public means that the document is publicly accessible using the public URL. Permissioned means that it is private and requires shared access to be enabled for a user to be able to view it.

    Type - For Document Profile Assets this will always be ‘Document’.

    Description - an optional description of the Asset

    Attributes - This drop down section contains any custom attributes that were added to the asset.

    Versions - the published versions of the document

    Note: The share button allows you to access and copy the permissioned and public (if enabled) links for the asset to share with other users. Private links are for logged in users with permissions assigned in an Access Policy, Public links are for everyone.
    Share Links

    The Event History tab shows the full history of Events including custom Events, new Versions and Withdraw Events.

    Click on the tab and select an Event to view the details.

    Event History Overview Tab

    The Overview information about the Event

    Event Identity - The Event ID will always be of the format ‘publicassets/<asset_id>/events/<event_id>’ for public assets or ‘assets/<asset_id>/events/<event_id>’ for private assets.

    Asset Identity - the ID of the parent Asset for this Event.

    Transaction - This link contains the details of the blockchain transaction.

    Transaction Details

    Type - For Document Profile Events this will always be ‘Publish’

    Document changes - The version and document hash for new version Events. There is no data here for custom Events.

    The Event attributes and Asset attributes tabs contain information about any custom attributes that were added or modified as part this Event.

    ← Registering an Event Against a Document Profile Asset
    Public Attestation →
    \ No newline at end of file diff --git a/platform/overview/introduction/index.html b/platform/overview/introduction/index.html index 832bab642..fdcf5da84 100644 --- a/platform/overview/introduction/index.html +++ b/platform/overview/introduction/index.html @@ -8,4 +8,4 @@ Sign Up

    Introduction

    Welcome to DataTrails

    DataTrails provides Provenance as a Service that continuously proves Who Did What When to all data types.

    DataTrails enables enterprises to build trust in data such as documents, images and sound files by ensuring that you know the origin and history of the data that you are using. -This can also be applied to multi-party Assets such as software and physical items allowing you to make sure that processes are fit for purpose to comply with IT controls, corporate policies, and government regulations.

    DataTrails permanently records evidence into an Immutable Audit Trail to bring the right level of trust in data for faster, confident decisions with lower business risk by combining:

    Metadata Governance - Empower the right people in organizations to set, enforce, and execute complex data sharing policies.

    Authenticated Provenance - Deliver full traceability on all internal and external data sources to speed and assure digital decisions.

    Continuous Accountability - Instantly auditable evidence “Proves Who Did What When” for any shared Asset to delight your GRC team.

    Persistent Integrity - Create a complete, unbroken, and permanent record of shared Event transactions, delivering continuous assurance for faster digital decisions.

    DataTrails delivers assured metadata in a single line of code in a way that makes recording and auditing the full lifecycle of a piece of data simple. Any authorized participant (including a user, a software agent or an endpoint device) can register the Events that they are involved in.
    Users of the data can see a full picture of the data’s origin and history and by understanding Who Did What When, human actors and software/AI systems can make stronger real-time judgments about the trustworthiness of your data.

    Core Concepts →
    \ No newline at end of file +This can also be applied to multi-party Assets such as software and physical items allowing you to make sure that processes are fit for purpose to comply with IT controls, corporate policies, and government regulations.

    DataTrails permanently records evidence into an Immutable Audit Trail to bring the right level of trust in data for faster, confident decisions with lower business risk by combining:

    Metadata Governance - Empower the right people in organizations to set, enforce, and execute complex data sharing policies.

    Authenticated Provenance - Deliver full traceability on all internal and external data sources to speed and assure digital decisions.

    Continuous Accountability - Instantly auditable evidence “Proves Who Did What When” for any shared Asset to delight your GRC team.

    Persistent Integrity - Create a complete, unbroken, and permanent record of shared Event transactions, delivering continuous assurance for faster digital decisions.

    DataTrails delivers assured metadata in a single line of code in a way that makes recording and auditing the full lifecycle of a piece of data simple. Any authorized participant (including a user, a software agent or an endpoint device) can register the Events that they are involved in.
    Users of the data can see a full picture of the data’s origin and history and by understanding Who Did What When, human actors and software/AI systems can make stronger real-time judgments about the trustworthiness of your data.

    Core Concepts →
    \ No newline at end of file diff --git a/platform/overview/public-attestation/index.html b/platform/overview/public-attestation/index.html index 28ec19ab2..a29b9205d 100644 --- a/platform/overview/public-attestation/index.html +++ b/platform/overview/public-attestation/index.html @@ -66,4 +66,4 @@ Assets API

    ← Instaproof
    Identity and Access Management →
    \ No newline at end of file +

    ← Instaproof
    Identity and Access Management →
    \ No newline at end of file diff --git a/platform/overview/registering-a-document-profile-asset/index.html b/platform/overview/registering-a-document-profile-asset/index.html index 84b612c0c..db020d48d 100644 --- a/platform/overview/registering-a-document-profile-asset/index.html +++ b/platform/overview/registering-a-document-profile-asset/index.html @@ -191,4 +191,4 @@ https://app.datatrails.ai/archivist/v2/assets?attributes.arc_display_name=My%20First%20Document

    Here we see all details entered: The extended attributes and a history of Events recorded on the Document.

    Note: To update the details of your Asset after it has been created, you must create an Event containing Asset Attributes that conform to the Document Profile.

    For more information on creating Events, -click here.

    The first Event in the Event History will always be the Document Registration. In the next section, we will cover how to create your own Events for your Document.

    ← Creating an Event Against an Asset
    Registering an Event Against a Document Profile Asset →
    \ No newline at end of file +click here.

    The first Event in the Event History will always be the Document Registration. In the next section, we will cover how to create your own Events for your Document.

    ← Creating an Event Against an Asset
    Registering an Event Against a Document Profile Asset →
    \ No newline at end of file diff --git a/platform/overview/registering-an-event-against-a-document-profile-asset/index.html b/platform/overview/registering-an-event-against-a-document-profile-asset/index.html index bf4c7a156..db59d4406 100644 --- a/platform/overview/registering-an-event-against-a-document-profile-asset/index.html +++ b/platform/overview/registering-an-event-against-a-document-profile-asset/index.html @@ -183,4 +183,4 @@

    To view the details of the Event you just created for My First Document, use:

    curl -v -X GET \
      -H "@$HOME/.datatrails/bearer-token.txt" \
      https://app.datatrails.ai/archivist/v2/assets/<asset-id>/events/<event-id>
-

    ← Registering a Document Profile Asset
    Instaproof →
    \ No newline at end of file +

    ← Registering a Document Profile Asset
    Instaproof →
    \ No newline at end of file diff --git a/platform/overview/sitemap.xml b/platform/overview/sitemap.xml index 0dbf626da..e9f9a9138 100644 --- a/platform/overview/sitemap.xml +++ b/platform/overview/sitemap.xml @@ -1 +1 @@ -/platform/overview/introduction/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/core-concepts/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/advanced-concepts/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/creating-an-asset/2021-05-18T14:52:25+01:00weekly0.5/platform/overview/creating-an-event-against-an-asset/2021-05-18T15:32:01+01:00weekly0.5/platform/overview/registering-a-document-profile-asset/2023-06-29T15:11:03+01:00weekly0.5/platform/overview/registering-an-event-against-a-document-profile-asset/2023-07-26T13:07:55+01:00weekly0.5/platform/overview/instaproof/2023-07-18T12:10:19+01:00weekly0.5/platform/overview/public-attestation/2021-05-18T14:52:25+01:00weekly0.5 \ No newline at end of file +/platform/overview/introduction/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/core-concepts/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/advanced-concepts/2024-03-19T10:57:58+01:00weekly0.5/platform/overview/creating-an-asset/2021-05-18T14:52:25+01:00weekly0.5/platform/overview/creating-an-event-against-an-asset/2021-05-18T15:32:01+01:00weekly0.5/platform/overview/registering-a-document-profile-asset/2023-06-29T15:11:03+01:00weekly0.5/platform/overview/registering-an-event-against-a-document-profile-asset/2023-07-26T13:07:55+01:00weekly0.5/platform/overview/instaproof/2023-07-18T12:10:19+01:00weekly0.5/platform/overview/public-attestation/2021-05-18T14:52:25+01:00weekly0.5 \ No newline at end of file diff --git a/platform/sitemap.xml b/platform/sitemap.xml index 3889a9182..9a194b797 100644 --- a/platform/sitemap.xml +++ b/platform/sitemap.xml @@ -1 +1 @@ -/platform/administration/2023-06-01T10:14:18+01:00weekly0.5/platform/overview/2021-05-20T12:03:27+01:00weekly0.5/platform/administration/identity-and-access-management/2021-06-14T10:57:58+01:00weekly0.5/platform/administration/verified-domain/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/sharing-access-inside-your-tenant/2021-05-18T15:33:03+01:00weekly0.5/platform/administration/sharing-access-outside-your-tenant/2021-05-18T15:33:31+01:00weekly0.5/platform/administration/dropbox-integration/2023-09-15T13:18:42+01:00weekly0.5/platform/administration/compliance-policies/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/grouping-assets-by-location/2021-05-18T15:32:27+01:00weekly0.5/platform/overview/introduction/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/core-concepts/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/advanced-concepts/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/creating-an-asset/2021-05-18T14:52:25+01:00weekly0.5/platform/overview/creating-an-event-against-an-asset/2021-05-18T15:32:01+01:00weekly0.5/platform/overview/registering-a-document-profile-asset/2023-06-29T15:11:03+01:00weekly0.5/platform/overview/registering-an-event-against-a-document-profile-asset/2023-07-26T13:07:55+01:00weekly0.5/platform/overview/instaproof/2023-07-18T12:10:19+01:00weekly0.5/platform/overview/public-attestation/2021-05-18T14:52:25+01:00weekly0.5 \ No newline at end of file +/platform/administration/2023-06-01T10:14:18+01:00weekly0.5/platform/overview/2021-05-20T12:03:27+01:00weekly0.5/platform/administration/identity-and-access-management/2021-06-14T10:57:58+01:00weekly0.5/platform/administration/verified-domain/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/sharing-access-inside-your-tenant/2021-05-18T15:33:03+01:00weekly0.5/platform/administration/sharing-access-outside-your-tenant/2021-05-18T15:33:31+01:00weekly0.5/platform/administration/dropbox-integration/2023-09-15T13:18:42+01:00weekly0.5/platform/administration/compliance-policies/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/grouping-assets-by-location/2021-05-18T15:32:27+01:00weekly0.5/platform/overview/introduction/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/core-concepts/2021-06-14T10:57:58+01:00weekly0.5/platform/overview/advanced-concepts/2024-03-19T10:57:58+01:00weekly0.5/platform/overview/creating-an-asset/2021-05-18T14:52:25+01:00weekly0.5/platform/overview/creating-an-event-against-an-asset/2021-05-18T15:32:01+01:00weekly0.5/platform/overview/registering-a-document-profile-asset/2023-06-29T15:11:03+01:00weekly0.5/platform/overview/registering-an-event-against-a-document-profile-asset/2023-07-26T13:07:55+01:00weekly0.5/platform/overview/instaproof/2023-07-18T12:10:19+01:00weekly0.5/platform/overview/public-attestation/2021-05-18T14:52:25+01:00weekly0.5 \ No newline at end of file diff --git a/sales/contactus/index.html b/sales/contactus/index.html index ebe77a304..eb65408ef 100644 --- a/sales/contactus/index.html +++ b/sales/contactus/index.html @@ -5,4 +5,4 @@
    \ No newline at end of file +Sign Up
    \ No newline at end of file diff --git a/sales/index.html b/sales/index.html index 5d9811ece..35813abae 100644 --- a/sales/index.html +++ b/sales/index.html @@ -5,4 +5,4 @@
    \ No newline at end of file +Sign Up
    \ No newline at end of file diff --git a/sitemap.xml b/sitemap.xml index a4994b39a..f365074d2 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1 +1 @@ -/platform/overview/introduction/2021-06-14T10:57:58+01:00weekly0.5/usecases/authenticity-and-attestation/2021-05-31T15:18:01+01:00weekly0.5/developers/developer-patterns/getting-access-tokens-using-app-registrations/2023-09-27T11:12:25+01:00weekly0.5/platform/overview/core-concepts/2021-06-14T10:57:58+01:00weekly0.5/usecases/bill-of-materials/2021-05-31T15:18:01+01:00weekly0.5/platform/overview/advanced-concepts/2021-06-14T10:57:58+01:00weekly0.5/developers/developer-patterns/containers-as-assets/2021-05-31T15:18:01+01:00weekly0.5/usecases/state-machine/2021-05-31T15:18:01+01:00weekly0.5/platform/overview/creating-an-asset/2021-05-18T14:52:25+01:00weekly0.5/developers/developer-patterns/namespace/2021-05-31T15:18:01+01:00weekly0.5/platform/overview/creating-an-event-against-an-asset/2021-05-18T15:32:01+01:00weekly0.5/developers/developer-patterns/verifying-with-simple-hash/2021-05-18T14:52:25+01:00weekly0.5/platform/overview/registering-a-document-profile-asset/2023-06-29T15:11:03+01:00weekly0.5/developers/developer-patterns/document-profile/2021-05-31T15:18:01+01:00weekly0.5/platform/overview/registering-an-event-against-a-document-profile-asset/2023-07-26T13:07:55+01:00weekly0.5/developers/developer-patterns/software-package-profile/2023-06-26T11:56:01+01:00weekly0.5/platform/overview/instaproof/2023-07-18T12:10:19+01:00weekly0.5/platform/overview/public-attestation/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/identity-and-access-management/2021-06-14T10:57:58+01:00weekly0.5/platform/administration/verified-domain/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/sharing-access-inside-your-tenant/2021-05-18T15:33:03+01:00weekly0.5/platform/administration/sharing-access-outside-your-tenant/2021-05-18T15:33:31+01:00weekly0.5/platform/administration/dropbox-integration/2023-09-15T13:18:42+01:00weekly0.5/platform/administration/compliance-policies/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/grouping-assets-by-location/2021-05-18T15:32:27+01:00weekly0.5/glossary/common-datatrails-terms/2022-10-19T07:39:44-07:00weekly0.5/glossary/reserved-attributes/2022-10-19T07:39:44-07:00weekly0.5/developers/api-reference/app-registrations-api/2021-06-09T11:39:03+01:00weekly0.5/developers/api-reference/assets-api/2021-06-09T11:39:03+01:00weekly0.5/developers/api-reference/attachments-api/2021-06-09T12:05:02+01:00weekly0.5/developers/api-reference/blobs-api/2021-06-09T13:32:57+01:00weekly0.5/developers/api-reference/blockchain-api/2021-06-09T13:57:04+01:00weekly0.5/developers/api-reference/compliance-api/2021-06-09T12:07:13+01:00weekly0.5/developers/api-reference/events-api/2021-06-09T11:48:40+01:00weekly0.5/developers/api-reference/iam-policies-api/2021-06-09T12:02:15+01:00weekly0.5/developers/api-reference/iam-subjects-api/2021-06-09T12:02:15+01:00weekly0.5/developers/developer-patterns/scitt-api/2021-06-09T13:49:35+01:00weekly0.5/developers/api-reference/locations-api/2021-06-09T11:56:23+01:00weekly0.5/developers/api-reference/public-assets-api/2021-06-09T11:56:23+01:00weekly0.5/developers/api-reference/system-api/2021-06-09T13:49:35+01:00weekly0.5/developers/api-reference/tenancies-api/2021-06-09T13:29:57+01:00weekly0.5/developers/yaml-reference/story-runner-components/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/assets/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/events/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/locations/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/subjects/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/compliance/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/estate-info/2021-06-09T11:39:03+01:00weekly0.5/developers/developer-patterns/2023-05-31T10:14:18+01:00weekly0.5/developers/api-reference/caps-api/2024-03-05T11:30:29+00:00weekly0.5/platform/administration/2023-06-01T10:14:18+01:00weekly0.5/developers/yaml-reference/2023-05-31T10:14:18+01:00weekly0.5/glossary/2021-06-09T10:19:37+01:00weekly0.5/usecases/2021-05-20T17:42:10+01:00weekly0.5/developers/api-reference/2021-06-09T10:19:37+01:00weekly0.5/platform/overview/2021-05-20T12:03:27+01:00weekly0.5/developers/2020-10-06T08:48:23+00:00weekly0.5/platform/2020-10-06T08:48:23+00:00weekly0.5/2020-10-06T08:47:36+00:00weekly0.5/contributors/weekly0.5 \ No newline at end of file +/platform/overview/introduction/2021-06-14T10:57:58+01:00weekly0.5/usecases/authenticity-and-attestation/2021-05-31T15:18:01+01:00weekly0.5/developers/developer-patterns/getting-access-tokens-using-app-registrations/2023-09-27T11:12:25+01:00weekly0.5/platform/overview/core-concepts/2021-06-14T10:57:58+01:00weekly0.5/usecases/bill-of-materials/2021-05-31T15:18:01+01:00weekly0.5/platform/overview/advanced-concepts/2024-03-19T10:57:58+01:00weekly0.5/developers/developer-patterns/containers-as-assets/2021-05-31T15:18:01+01:00weekly0.5/usecases/state-machine/2021-05-31T15:18:01+01:00weekly0.5/platform/overview/creating-an-asset/2021-05-18T14:52:25+01:00weekly0.5/developers/developer-patterns/namespace/2021-05-31T15:18:01+01:00weekly0.5/platform/overview/creating-an-event-against-an-asset/2021-05-18T15:32:01+01:00weekly0.5/developers/developer-patterns/verifying-with-simple-hash/2021-05-18T14:52:25+01:00weekly0.5/platform/overview/registering-a-document-profile-asset/2023-06-29T15:11:03+01:00weekly0.5/developers/developer-patterns/document-profile/2021-05-31T15:18:01+01:00weekly0.5/platform/overview/registering-an-event-against-a-document-profile-asset/2023-07-26T13:07:55+01:00weekly0.5/developers/developer-patterns/software-package-profile/2023-06-26T11:56:01+01:00weekly0.5/platform/overview/instaproof/2023-07-18T12:10:19+01:00weekly0.5/platform/overview/public-attestation/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/identity-and-access-management/2021-06-14T10:57:58+01:00weekly0.5/platform/administration/verified-domain/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/sharing-access-inside-your-tenant/2021-05-18T15:33:03+01:00weekly0.5/platform/administration/sharing-access-outside-your-tenant/2021-05-18T15:33:31+01:00weekly0.5/platform/administration/dropbox-integration/2023-09-15T13:18:42+01:00weekly0.5/platform/administration/compliance-policies/2021-05-18T14:52:25+01:00weekly0.5/platform/administration/grouping-assets-by-location/2021-05-18T15:32:27+01:00weekly0.5/glossary/common-datatrails-terms/2022-10-19T07:39:44-07:00weekly0.5/glossary/reserved-attributes/2022-10-19T07:39:44-07:00weekly0.5/developers/api-reference/app-registrations-api/2021-06-09T11:39:03+01:00weekly0.5/developers/api-reference/assets-api/2021-06-09T11:39:03+01:00weekly0.5/developers/api-reference/attachments-api/2021-06-09T12:05:02+01:00weekly0.5/developers/api-reference/blobs-api/2021-06-09T13:32:57+01:00weekly0.5/developers/api-reference/blockchain-api/2021-06-09T13:57:04+01:00weekly0.5/developers/api-reference/compliance-api/2021-06-09T12:07:13+01:00weekly0.5/developers/api-reference/events-api/2021-06-09T11:48:40+01:00weekly0.5/developers/api-reference/iam-policies-api/2021-06-09T12:02:15+01:00weekly0.5/developers/api-reference/iam-subjects-api/2021-06-09T12:02:15+01:00weekly0.5/developers/developer-patterns/scitt-api/2021-06-09T13:49:35+01:00weekly0.5/developers/api-reference/locations-api/2021-06-09T11:56:23+01:00weekly0.5/developers/api-reference/public-assets-api/2021-06-09T11:56:23+01:00weekly0.5/developers/api-reference/system-api/2021-06-09T13:49:35+01:00weekly0.5/developers/api-reference/tenancies-api/2021-06-09T13:29:57+01:00weekly0.5/developers/yaml-reference/story-runner-components/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/assets/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/events/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/locations/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/subjects/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/compliance/2021-06-09T11:39:03+01:00weekly0.5/developers/yaml-reference/estate-info/2021-06-09T11:39:03+01:00weekly0.5/developers/developer-patterns/2023-05-31T10:14:18+01:00weekly0.5/developers/api-reference/caps-api/2024-03-05T11:30:29+00:00weekly0.5/platform/administration/2023-06-01T10:14:18+01:00weekly0.5/developers/yaml-reference/2023-05-31T10:14:18+01:00weekly0.5/glossary/2021-06-09T10:19:37+01:00weekly0.5/usecases/2021-05-20T17:42:10+01:00weekly0.5/developers/api-reference/2021-06-09T10:19:37+01:00weekly0.5/platform/overview/2021-05-20T12:03:27+01:00weekly0.5/developers/2020-10-06T08:48:23+00:00weekly0.5/platform/2020-10-06T08:48:23+00:00weekly0.5/2020-10-06T08:47:36+00:00weekly0.5/contributors/weekly0.5 \ No newline at end of file diff --git a/support/contactus/index.html b/support/contactus/index.html index 39a066af0..b9cd005c3 100644 --- a/support/contactus/index.html +++ b/support/contactus/index.html @@ -5,4 +5,4 @@

    Contact Us

    For any queries please contact support@datatrails.ai

    \ No newline at end of file +Sign Up

    Contact Us

    For any queries please contact support@datatrails.ai

    \ No newline at end of file diff --git a/support/index.html b/support/index.html index e6a8ec576..c9a40cefe 100644 --- a/support/index.html +++ b/support/index.html @@ -5,4 +5,4 @@
    \ No newline at end of file +Sign Up
    \ No newline at end of file diff --git a/usecases/authenticity-and-attestation/index.html b/usecases/authenticity-and-attestation/index.html index 77cc2932b..4c3814d9f 100644 --- a/usecases/authenticity-and-attestation/index.html +++ b/usecases/authenticity-and-attestation/index.html @@ -6,4 +6,4 @@

    Authenticity and Attestation

    Assurance with DataTrails

    A very simple yet powerful pattern for using DataTrails is the Authenticity pattern. This is a good choice when dealing with data or documents that need to be broadly proven. In a single action, files can be uploaded to DataTrails so their integrity, origin, and timestamps can be verified forever. Both private and public stakeholders relying on these files can verify that what they see on their screen is authentic and untampered.

    Example: Evidential Documents and Photographs

    There are a great many documents that serve as evidence in formal discussions: pictures of a traffic accident; education diplomas; contracts; statements of account. DataTrails adds strong integrity to any document to allow easy verification.

    Considerations

    Track Documents: Create a very simple Asset structure with minimal attributes to identify the document and store the key metadata, such as a hash of the document.

    Collections: If the document is strongly related to another one, consider adding and tracking them all as Events against a single Asset record.

    Versions: If the document is a new version of something already stored in DataTrails, then use Events to replace the document’s metadata with the updated version. Any authorized stakeholder fetching the Asset record will automatically get the most up-to-date version, and prior versions can be retrieved if necessary from the Event history.

    Bill of Materials →
    \ No newline at end of file +Use Cases

    Authenticity and Attestation

    Assurance with DataTrails

    A very simple yet powerful pattern for using DataTrails is the Authenticity pattern. This is a good choice when dealing with data or documents that need to be broadly proven. In a single action, files can be uploaded to DataTrails so their integrity, origin, and timestamps can be verified forever. Both private and public stakeholders relying on these files can verify that what they see on their screen is authentic and untampered.

    Example: Evidential Documents and Photographs

    There are a great many documents that serve as evidence in formal discussions: pictures of a traffic accident; education diplomas; contracts; statements of account. DataTrails adds strong integrity to any document to allow easy verification.

    Considerations

    Track Documents: Create a very simple Asset structure with minimal attributes to identify the document and store the key metadata, such as a hash of the document.

    Collections: If the document is strongly related to another one, consider adding and tracking them all as Events against a single Asset record.

    Versions: If the document is a new version of something already stored in DataTrails, then use Events to replace the document’s metadata with the updated version. Any authorized stakeholder fetching the Asset record will automatically get the most up-to-date version, and prior versions can be retrieved if necessary from the Event history.

    Bill of Materials →
    \ No newline at end of file diff --git a/usecases/bill-of-materials/index.html b/usecases/bill-of-materials/index.html index 4fa3a081e..170ab8dbf 100644 --- a/usecases/bill-of-materials/index.html +++ b/usecases/bill-of-materials/index.html @@ -11,4 +11,4 @@ NTIA SBOM Proof of Concept the need for strong stakeholder community management and a trusted SBOM data sharing mechanism which protects the interests of all parties.

    The DataTrails Software Package profile is a set of suggested Asset and Event attributes that offers a solution to this sharing and distribution problem: vendors retain control of their proprietary information and release processes while customers have assured and reliable visibility into their digital supply chain risks with reliable access to current and historical SBOM data for the components they rely on.

    As an Asset, a Software Package may hold many different SBOMs over its lifecycle representing the introduction of new releases and versions of the Software Package. Each ‘Release’ is recorded as an Event to capture the known SBOM at the time.

    If a particular Software Package has constituent components composed of other Software Package Assets this would be tracked within the SBOM of the component Supplied Software Package, ensuring full traceability across the Supply Chain.

    Considerations

    Key to any successful DataTrails integration is keeping the number of Asset attributes manageable and meaningful. Do not add every entry in the SBOM as an Asset attribute. Instead, preserve Asset attributes to carry essential metadata such as final build hashes and assured current versions, and put the full details of each released version in attachments and Events.

    Note: There are good standards for storing and exchanging SBOM data such as SWID/ISO/IEC 19770-2:2015, Cyclone DX, and -SPDX. DataTrails recommends adopting standard data formats wherever possible, as these vastly improve interoperability and utility of the data exchanged between DataTrails participants.

    SBOM as a living document: As a vendor, try to model each final software product as an Asset, and releases/updates to that software product as Events on that Asset. That way, a single Asset history contains all the patch versions of a pristine build standard.

    Link to real assets: In reality, not every machine is going to be patched and running identical versions of software, and certainly not the most up-to-date one. As a user of devices, try to link the SBOM from your vendor to the device by having Asset attributes for the Asset Identity of the vendor-published SBOM and the version installed on the device. That way it is easy to find devices that need attention following an SBOM update.

    Access Policies: Always try to avoid proliferating Access Policies and make as few as possible with clear user populations and access rights. Typically, very few parties need to update the SBOM record, but many people will need to read it.

    Remember that DataTrails is a shared evidence platform. It is there to help share and publish the SBOM and create the trust and transparency that is demanded of modern systems, to ensure the security of the digital supply chain.

    ← Authenticity and Attestation
    State Machine and Supply Chains →
    \ No newline at end of file +SPDX. DataTrails recommends adopting standard data formats wherever possible, as these vastly improve interoperability and utility of the data exchanged between DataTrails participants.

    SBOM as a living document: As a vendor, try to model each final software product as an Asset, and releases/updates to that software product as Events on that Asset. That way, a single Asset history contains all the patch versions of a pristine build standard.

    Link to real assets: In reality, not every machine is going to be patched and running identical versions of software, and certainly not the most up-to-date one. As a user of devices, try to link the SBOM from your vendor to the device by having Asset attributes for the Asset Identity of the vendor-published SBOM and the version installed on the device. That way it is easy to find devices that need attention following an SBOM update.

    Access Policies: Always try to avoid proliferating Access Policies and make as few as possible with clear user populations and access rights. Typically, very few parties need to update the SBOM record, but many people will need to read it.

    Remember that DataTrails is a shared evidence platform. It is there to help share and publish the SBOM and create the trust and transparency that is demanded of modern systems, to ensure the security of the digital supply chain.

    ← Authenticity and Attestation
    State Machine and Supply Chains →
    \ No newline at end of file diff --git a/usecases/index.html b/usecases/index.html index 7837c4d4b..e81a26779 100644 --- a/usecases/index.html +++ b/usecases/index.html @@ -7,4 +7,4 @@

    Use Cases

    DataTrails is a powerful and flexible platform enabling users to record Who Did What & When to any content. To get the best out of the DataTrails it is important to model your real-world assets and business processes efficiently into DataTrails Assets and -Events.

    The three most common patterns are:

    • Authenticity and Attestation: proving the state of documents and data at a point in time. Also known as ‘Provenance’.
    • Bill of Materials: tracing the contents and composition of assets.
    • State Machine and Supply Chains: following the progress of an asset as it moves through a business process or lifecycle states.

    These are laid out in more detail here:


    \ No newline at end of file +Events.

    The three most common patterns are:

    • Authenticity and Attestation: proving the state of documents and data at a point in time. Also known as ‘Provenance’.
    • Bill of Materials: tracing the contents and composition of assets.
    • State Machine and Supply Chains: following the progress of an asset as it moves through a business process or lifecycle states.

    These are laid out in more detail here:


    \ No newline at end of file diff --git a/usecases/state-machine/index.html b/usecases/state-machine/index.html index 330e27289..87222ab90 100644 --- a/usecases/state-machine/index.html +++ b/usecases/state-machine/index.html @@ -6,4 +6,4 @@

    State Machine and Supply Chains

    Using DataTrails to map a process

    A common pattern for tracking an Asset lifecycle is the State Machine pattern. This is a good choice for multi-stakeholder process modelling, particularly where the order of operations is important or activities are triggered by actions of partners. Tracing multi-stakeholder business processes in DataTrails not only ensures transparency and accountability among parties, but is also faster and more reliable than typical cross-organization data sharing and process management involving phone calls and spreadsheets.

    Modelling such systems in DataTrails can help to rapidly answer questions like “are my processes running smoothly?”, “do I need to act?”, and “has this asset been correctly managed?”. In audit situations, the Asset histories also allow stakeholders to look back in time and ask “who knew what at the time? Could process violations have been detected earlier?”

    Example 1: Multi-party change management and approvals

    This pattern uses a purely virtual Asset to represent a policy or process and coordinate movement through that process, complete with multi-party inputs and approvals. The emphasis here is on Events rather than Asset attributes: What Happened? Who Was There? What evidence was used to decide to move to the next sage of the process?

    Considerations

    Keep the Asset simple: This model typically uses mostly non-modifying Events: “what happened” is more important than “what does this Asset look like?”. Use Asset attributes only to clearly identify the business process and store its current state. Otherwise, concentrate on recording the Who Did What When in detailed Event attributes and attachments.

    Map the business process: DataTrails is here to support business operations, not disturb them. Try to define one Event type for each stage of the process, so decisions and artifacts can be recorded naturally and completely during normal operations. In a mature business, there may be formal documents such as a Process Map (PM), Business Process Model (BPM) or Universal Modeling Language description of the process, its steps, and its approvers. Use this as a base if it is available.

    Record decisions clearly: Future decisions will depend on the evidence of past ones. Make sure that all relevant information is recorded in Event records in the right format for the intended consumer: if decisions are made by humans, rich attachments are a good option. If software or AI are involved, then Event attributes are often a stronger choice.

    Access Policies: Always try to avoid proliferating Access Policies and make as few as possible with clear user populations and access rights. Generally, all parties will need read access to all the Events in the Asset history, but it may be convenient to restrict Event write access to mirror real-world approvers and actors.

    Example 2: Asset lifecycle tracing

    Tracking and tracing the lifecycle of physical Assets - from IoT Devices to skyscrapers - is a key strength of DataTrails. The ability to collect and examine the entire life history of critical Assets - their provenance - is crucial to building secure and trustworthy systems.

    Knowing what state an asset is in, whether or not it is compliant with organizational policy, and whether it needs any attention right now can help a connected system run smoothly. This eliminates the mundane in lifecycle management and allows expert resources to focus only on those parts of the estate that need attention.

    Considerations

    Build the Asset over time: The Asset lifecycle covers its entire life, from design and build to procurement and use, and finally disposal. During this time the Asset evolves and develops new properties and characteristics which are not necessarily foreseeable at creation time. DataTrails supports the addition of new properties at any time in the lifecycle so there is no need to design and fill in everything up-front. Start with a simple - even empty - Asset and let DataTrails track and trace the new properties as they naturally occur.

    Verify and confirm security data: For digital Assets, a lot of the effort spent on lifecycle management will be spent on software and firmware management. DataTrails’s ‘Witness Statement’ approach to creating Asset histories enables statements of intent to be recorded alongside ground truths. For example, a claimed software update next to a digitally signed platform attestation proving that it was done.

    Access Policies: Always try to avoid proliferating Access Policies and make as few as possible with clear user populations and access rights. Generally, all parties will need read access to all the Events in the Asset history but it may be convenient to restrict Event write access to mirror real-world approvers and actors.

    Example 3: Supply Chain Handling

    “Multi-party business processes” and “Asset lifecycle tracing” are examples of a more general pattern: Supply Chain Handling.

    The ‘State Machine’ and ‘Lifecycle Tracing’ pattens are very similar, but the former puts a greater emphasis on modeling and tracing the Events while the latter concentrates more on the evolving state of the Assets. Combining these concepts makes it possible to easily trace complex multi-party supply chains without stakeholders having to adapt to each other’s ways of working. Everyone participates on their own terms using their own tools and processes, and DataTrails bridges the gap to make data available where it is needed.

    Considerations

    GIS position information: Make good use of the =arc_gis_*= attributes of Events in order to trace Where Who Did What When. Remember that physical environment can make a lot of difference to the virtual security of your Assets.

    Access Policies 1: Always try to avoid proliferating Access Policies and make as few as possible with clear user populations and access rights. Nonetheless, complete supply chain operations are complex and thought must be given to Access Policy configuration to account for changes of custody.

    Access Policies 2: Consider how far up or down the supply chain visibility should be offered. For example, a customer/operator should be able to see manufacturing data but the manufacturer may or may not be entitled to see usage data.

    ← Bill of Materials
    \ No newline at end of file +Use Cases

    State Machine and Supply Chains

    Using DataTrails to map a process

    A common pattern for tracking an Asset lifecycle is the State Machine pattern. This is a good choice for multi-stakeholder process modelling, particularly where the order of operations is important or activities are triggered by actions of partners. Tracing multi-stakeholder business processes in DataTrails not only ensures transparency and accountability among parties, but is also faster and more reliable than typical cross-organization data sharing and process management involving phone calls and spreadsheets.

    Modelling such systems in DataTrails can help to rapidly answer questions like “are my processes running smoothly?”, “do I need to act?”, and “has this asset been correctly managed?”. In audit situations, the Asset histories also allow stakeholders to look back in time and ask “who knew what at the time? Could process violations have been detected earlier?”

    Example 1: Multi-party change management and approvals

    This pattern uses a purely virtual Asset to represent a policy or process and coordinate movement through that process, complete with multi-party inputs and approvals. The emphasis here is on Events rather than Asset attributes: What Happened? Who Was There? What evidence was used to decide to move to the next sage of the process?

    Considerations

    Keep the Asset simple: This model typically uses mostly non-modifying Events: “what happened” is more important than “what does this Asset look like?”. Use Asset attributes only to clearly identify the business process and store its current state. Otherwise, concentrate on recording the Who Did What When in detailed Event attributes and attachments.

    Map the business process: DataTrails is here to support business operations, not disturb them. Try to define one Event type for each stage of the process, so decisions and artifacts can be recorded naturally and completely during normal operations. In a mature business, there may be formal documents such as a Process Map (PM), Business Process Model (BPM) or Universal Modeling Language description of the process, its steps, and its approvers. Use this as a base if it is available.

    Record decisions clearly: Future decisions will depend on the evidence of past ones. Make sure that all relevant information is recorded in Event records in the right format for the intended consumer: if decisions are made by humans, rich attachments are a good option. If software or AI are involved, then Event attributes are often a stronger choice.

    Access Policies: Always try to avoid proliferating Access Policies and make as few as possible with clear user populations and access rights. Generally, all parties will need read access to all the Events in the Asset history, but it may be convenient to restrict Event write access to mirror real-world approvers and actors.

    Example 2: Asset lifecycle tracing

    Tracking and tracing the lifecycle of physical Assets - from IoT Devices to skyscrapers - is a key strength of DataTrails. The ability to collect and examine the entire life history of critical Assets - their provenance - is crucial to building secure and trustworthy systems.

    Knowing what state an asset is in, whether or not it is compliant with organizational policy, and whether it needs any attention right now can help a connected system run smoothly. This eliminates the mundane in lifecycle management and allows expert resources to focus only on those parts of the estate that need attention.

    Considerations

    Build the Asset over time: The Asset lifecycle covers its entire life, from design and build to procurement and use, and finally disposal. During this time the Asset evolves and develops new properties and characteristics which are not necessarily foreseeable at creation time. DataTrails supports the addition of new properties at any time in the lifecycle so there is no need to design and fill in everything up-front. Start with a simple - even empty - Asset and let DataTrails track and trace the new properties as they naturally occur.

    Verify and confirm security data: For digital Assets, a lot of the effort spent on lifecycle management will be spent on software and firmware management. DataTrails’s ‘Witness Statement’ approach to creating Asset histories enables statements of intent to be recorded alongside ground truths. For example, a claimed software update next to a digitally signed platform attestation proving that it was done.

    Access Policies: Always try to avoid proliferating Access Policies and make as few as possible with clear user populations and access rights. Generally, all parties will need read access to all the Events in the Asset history but it may be convenient to restrict Event write access to mirror real-world approvers and actors.

    Example 3: Supply Chain Handling

    “Multi-party business processes” and “Asset lifecycle tracing” are examples of a more general pattern: Supply Chain Handling.

    The ‘State Machine’ and ‘Lifecycle Tracing’ pattens are very similar, but the former puts a greater emphasis on modeling and tracing the Events while the latter concentrates more on the evolving state of the Assets. Combining these concepts makes it possible to easily trace complex multi-party supply chains without stakeholders having to adapt to each other’s ways of working. Everyone participates on their own terms using their own tools and processes, and DataTrails bridges the gap to make data available where it is needed.

    Considerations

    GIS position information: Make good use of the =arc_gis_*= attributes of Events in order to trace Where Who Did What When. Remember that physical environment can make a lot of difference to the virtual security of your Assets.

    Access Policies 1: Always try to avoid proliferating Access Policies and make as few as possible with clear user populations and access rights. Nonetheless, complete supply chain operations are complex and thought must be given to Access Policy configuration to account for changes of custody.

    Access Policies 2: Consider how far up or down the supply chain visibility should be offered. For example, a customer/operator should be able to see manufacturing data but the manufacturer may or may not be entitled to see usage data.

    ← Bill of Materials
    \ No newline at end of file