Digital assets are:
- Applications and processes
- Data
Allowing humans to login to your IT systems (applications, processes), or allowing an process owned by another party to access (read and maybe modify) your data is the subject of Digital Asset Boundary Management.
This subject is well understood by most organizations and covered by the main parts of the Trust Kit:
- Digital Identification
- Authentication
- Authorization
Usually, many parties are involved in a logistic process. Each of these parties maintains a set of valuable assets that they needs to protect. In abstract terms, this protection is realized by creating an perimeter, a boundary around the assets that is controlled by the party. Other parties can not cross the boundary without permission of the owner, hence the value is protected. However it is often required that parties do cross the boundary to facilitate cooperation.
Three different kinds of assets and their associated boundaries are distinguished:
Digital assets, such as IT systems (applications, processes) and data
Physical assets, such as distribution centers and production facilities
Legal (ownership, liability and accountability) assets, such as responsibilities for and ownership of cargo
The nature and implementation of the protecting boundaries is different for each kind of assets and each one requires specific measures to allow third parties to cross them in order to cooperate in a logistic process.
There are two reasons to allow others (representatives as in humand and IT-processes) to cross a boundary:
To allow them to use an asset
To transfer an asset between parties
Boundary Management is about managing boundaries in practice.
Boundary Management relates to:
Identity (M2M and H2M)
Authentication (M2M and H2M)
Authorisation
Federation
Trade leads to transport
Transport is almost always a consequence of trade. In the delivery conditions of a purchase agreement, the seller and buyer agree, among other things, who must take care of the transport of the shipment.
In international trade, seller and buyer can use the Incoterms 2020. These are standardized agreements about who arranges what (for example transport, but also insurance and/or customs formalities), payment and payment guarantees, and the moment at which responsibility is transferred (for example when a container is lifted over the rail of a ship). Incoterms 2020 are mainly focused on the agreements between buyer and seller.
Transport agreement
As a result of the agreements in the purchase agreement, one of the parties gives one or more orders to arrange transport. In a more complex chain, forwarders often arrange the details on behalf of the client, but in the case of a relatively simple order this is usually done directly.
Digital transfer of accountability and liability
Paper documents have been the standard in the professional transport of goods for centuries. They serve as a basis for business agreements ('contracts': agreements, insurance, credits), as a means to coordinate activities ('coordination': coordination in the transport chain), and as a basis for declarations to and inspections by governments ('compliance' : demonstrate that one complies with the applicable legislation). Many laws, work processes and customs are based on this paper backbone.
The new standard is digital. Mutual agreements, planning, transactions, transfers and notifications are handled as much as possible by the IT systems of the companies and governments involved. Automated, with less and less human intervention, to facilitate:
Demonstrability: being able to show the origin of goods and the environmental effects of a supply chain.
Managing scarcity: scarce infrastructure, labor shortages, limited environmental space and shortages of raw materials, energy or products. The only way to make well-founded choices is to provide more information and insight.
Resilience: absorbing the consequences of disruptions and shocks in the global economy.
Preventing undermining: both cutting off opportunities for crime and fraud, preventing and detecting tax evasion.
Legal asset boundary management
Just like a stamp or a 'wet' signature on paper, it's all about the details that determine how much legal strength a digitally recorded transaction has. And on the other hand, the desire or necessity of the parties involved (client, transporter and recipient) to set high, low or no requirements at all: even not to build in digital transaction recording at all.
There are many more digital variants than 'analogue'. And all of them have their specific properties, advantages and disadvantages. The legal status of variants (other than high quality "digital signatures" for valuable transactions) is diffuse.
As there is no global accepted standard or legal franework for "fit for use" recordings of digital transactions, the BDI supports commercial agreements between parties, called Edge Agreements.
Standardized protocols with corresponding liability definitions can be referenced in general conditions of agreements, creating the legal basis for "fit for use" Legal Asset Boundary Management.
The BDI framework includes support for the authentication of a representative (human or machine) and verification of their mandate, safeguarding the non-repudiation of the liability their principal ( the entity who is represented) takes for their actions.
In the physical operation of our economy many activities are outsourced. Supplying services on-premise reauires access to a guarded location. For example: a maintenance sub-contractor for a vendor of video security systems is commissioned to perform maintenance at a customer's site. The subcontractor is contracted to perform regular maintenance . At regular intervals a maintenance engineer shows up at the gate of the premises and claims access to the premises, to perform preventive maintenance on a security video system on behalf of the vendor that delivered the security system.
The security guard of the company where the security system is installed needs to verify: has he/she indeed been sent by the OEM? And can he/she indeed be authenticated and verified as being mandated by the sub-contractor, and does he/she have the required professional qualifications? And can that mandate be verified in a non-repudiable manner?
User Journey
In the example of the engineer of the maintenance sub-contractor, the user journey starts when the engineer shows up to the gate. The security guard needs to be able to authenticate the person and verify the representation claim.
The approach is that the engineer presents an ID (proof for authentication) and a Representation Evidence.
The ID can be standard, fitted with additional safeguards such as biometrics, or digital (Wallet).
The Representation Evidence should be able to show:
- The chain of subcontracting, up to a level that is suitable for security reasons
It may be necessary to stop at an intermediate level, to protect the identity of the main principal on top of the chain from leaking
- The confirmation of the identity of the engineer, as a representative
- Time limitations on the validity of the representation (not before, not after)
- Links to issuers of subcontracting orders, to validate real-time is the representation is still valid and not revoked
- The non-repudiable evidence of the representation
For real-life applications it is necessary to be able to operate (temporarily) offline: the check of the Representation Evidence with delayed validation at the issuers should be possible. If a delayed verification is acceptable is up to the parties involved: in many cases this might be acceptable, for instance if a pre-notification is done to the party that is checking the Representation Evidence. The pre-notification data can be matched with the data in de Evidence.
Nested JWT as carrier of claims
JSON Web Token (JWT, RFC 7519) is a compact, URL-safe means of representing claim sets to be transferred between two parties. A claim set is just a set of claims, where each claim is a piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a claim name (always a string) and a claim value (can be any JSON value).
The use of JWT is ubiquitous: the support in tools and knowhow is well developed.
Unsecured JWTs are just standardized claim sets. However, many if not most JWTs need to be signed and encrypted. The claim set in a JWT can be used as the payload of a JSON Web Signature (JWS, RFC 7515) structure or as the plaintext of a JSON Web Encryption (JWE, RFC 7516) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
The result nesting of a JWT in a JWS or in a JWE (or both!) is called a Nested JWT. (Note that this is a different kind of nesting than the nesting/embedding of representation evidences that are the topic of this note). The resulting JSON object is encoded using a Base64URL encoding, which produces a URL-safe plain ASCII string.
Because JWTs are in the end just ASCII strings, they can be used as the value of a claim in another JWT. We will designate this kind of nesting as embedded JWTs. This feature is the basis for representation hierarchies, where a representation is based on another representation.
A draft JWT specification https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ defines how to implement selective disclosure of information. Selective disclosure would be a excellent feature in business environments.
JWT types of claims
There are two types of JWT claims:
· Registered: standard claims registered with the Internet Assigned Numbers Authority (IANA) and defined by the JWT specification to ensure interoperability with third-party, or external, applications.
· Custom: consists of non-registered public or private claims. Public claims are collision-resistant while private claims are subject to possible collisions
The IANA "JSON Web Token Claims" registry https://www.iana.org/assignments/jwt/jwt.xhtml#claims lists the registered claims.
Verifiable Credentials https://www.w3.org/TR/vc-data-model-2.0/ (Claim Name “vc”) and Verifiable Presentations (Claim Name “vp”) are registered claims.
The use of nested JWTs supports the future use of VC’s and VP’s.
The JWT structure makes it therefore possible to include claims of Professional Qualifications.
Using JWT's as carrier of Representation claims
The most simple approach is that the Pinricpal issues the JWT. The payload of the JWT is:
identity information of the human (ID #, name, digital identity etc.)
idenity information of the Principal
order information (order reference, type of activity, location, data)
additional information (time limits, specific instructions, link to issuer)
The issuer of the JWT (Principal) can add a link to the payload. The link allows for a real-time confirmation that the claims in the JWT are still valid.
When the Principal commissions a subcontractor, the identity of the human is replaced by the identity of the subcontractor. The subcontractor creates a new JWT, with the payload:
the JWT as sent by the Principal
identity information of the human (ID #, name, digital identity etc.)
idenity information of the Subcontratcor)
order information (subcontractor order reference, type of activity, location, data)
additional information (time limits, specific instructions, link to issuer)
Application in practice
An embedded JWT claim can be created recursively by each layer of the (subcontracting) chain, starting with a Principal. This show the Representation chain.
The human requesting access can carry the JWT (for instance in a Wallet), or carry a link to an online API that can transfer the JWT to an evaluation service/application. The security guards use the service or application to evaluate the JWT, verify the signing of its claims and show the content to the guard. The guard can authenticate the human and verify the representation chain.
Further reading
This page contains references to demo projects and their lessons learned where the Boundary Management has been used.