Concepts
Introduction
The concept is to define an Ubiquitous Language upon for the Trust1Connector (T1C). The T1C contains the following modules:
T1C-GCL (Generic Connector Library)
T1C-JS (Trust1Connector JavaScript client)
T1C-DS (Trust1Connector Distribution Service)
T1G (Trust1Gateway)
A managed Trust1Connector doesn't need T1G and T1C-DS, and thus can operate without dependencies towards a back-end service.
Component Overview
Overal Concept
Web/native application is always in control. The approach is a Consumer driven orchestration. An important design decision is made for communication with hardware peripherals and back-end services (APIs), in order for the consuming application to be able to 'orchestrate' the entire business flow - from an end-user perspective. This approach benefits integration, responsibility, scalability, performance, extendability, loosely coupling. The following image denotes the concept: a user is interacting with an web/native application
the application, as T1C-GCL consumer, can decide upon the use case to be executed
the application, as a T1C-DS API consumer, can decide upon the service to be requested
Generic Connector Library
The T1C-GCL is a native client service, build for all supported operation systems, exposing browser independent service. The service exposed by T1C-GCL consists of:
core services
plugins services
Core services are services related to hardware communication and mainly implements hardware specific communication protocols. Plugins services are services build on top of the core service in order to provide client-consumer data towards browser web applications or other native applications running on the targeted client.
T1C-GCL - Core
Installer
An installer is a pre-compile T1C-GCL distribution wrapped in an OS dependent installer. Installers or 'executables' are tagged with a version.
Hardware Peripherals
Hardware peripherals are the 'pluggable' hardware components, implemented by the 'core' of T1C-GCL which are accessible from a browser context. In order to access different hardware peripherals, HwP should be categorized, and should provide an 'pluggable hardware interface' based on given specifications. This is, hardware peripherals are following a classification, in the core of T1C-GCL, based on the supported communication specifications available.
Pluggable hardware protocols
Hardware device can be addressed using protocol-based interfaces. The core T1C-GCL will implement different specifications in order to support a range of hardware peripherals, following those specifications.
Communication specifications
A communication specification is an ISO/IEC, RFC, IETF or other specification or open standard; with a strong focus on secured communication for hardware peripherals.
Reader Interface
The 'reader interface' is the interface exposed in order to access smart card readers following the aforementioned communication specifications. The T1C-GCL core will expose communication related interfaces in order to be consumers by plugins; plugins can be hosted on top of the T1C-GCL core in a concept called 'T1C-GCL plugin framework'. The reader interface exposes functionality in order to communicate with contact or contact-less smart cards, USB tokens, Bluetooth devices, ...
Smartcard
A smart card is any pocket-sized card that has embedded integrated circuits and follows the following specifications:
ISO/IEC 14443
ISO/IEC 7816
Session
When referring to a session, the documentation uses by default smart card sessions, or more generic: a session, including state, in a hardware communication channel. When a session is used in a browser context, the documentation will specify the session type when relevant.
TX
TX (Transaction) is an APDU transaction. The transaction can be executed in a session or as a single operation (implicit open session, execute transaction, close session).
RX
RX (Transaction Response) is an APDU transaction response. The transaction response is the result of an executed APDU request.
STX
STX (Secured Transaction). A secured transaction is a transaction containing a encrypted data block of one or more APDU commands. The data block of an STX command can not be intercepted in a browser but is executed in the context of a reader.
T1C-GCL - Plugin Framework
The T1C-GCL framework exposes interface for hardware communication following approved standards and specifications. The T1C-GCL facilitates browser independent communication with local hardware devices. The major benefits of the T1C-GCL are:
browser independent
light-weight service with minimal footprint
multi-host plugin versions
no underlying compiler or JVM needed
management of plugin capabilities
shared core for unmanaged devices-
Private Plugin
A private plugin is a plugin developed during a project in the context of a T1T customer/partner. Private plugins are plugins targeted for a specific audience, and compiled as a binary file (C++) - when the logic must not be readable, or as script files (Lua) - when the logic can be readable. Private plugins are not available in a community edition, and can only be installed on a T1C-GCL after customer/partner approval. A private plugin is hosted in a private repository.
Community Plugin
A community plugin is an implementation of business logic, using T1C-GCL hardware communication interfaces, in order to consumer user-related or device-related content. A community Plugin is available online in a public repo.
Distribution Service
The T1C-GCL Distribution Service distributes and manages T1C-GCL instances for unmanaged and optionally managed devices.
Token issuance
The T1C-GCL API is a local service that can be used for web applications or native applications. The T1C-GCL public or community plugins can be consumed without additional security; in the context of smart cards, a smart card can be seen as uncoupled storage that is held by an end-user. The end-user can decide to enter a smart card in a reader, and thus enable the service consumption towards an application. For private plugins, additional security measures are provided upon the service accessibility. For a private plugin, the service can be available 'only' or 'partially' with a valid JWT.
Versioning
All artifacts are versioned following the principles of Semantic Versioning .
Device
A device can be a desktop pc, a mobile device with or without browser capabilities. A Device can use T1C-GCL in on- or off-line modus; a device can use T1C-GCL from native or web applications.
Upon activation a device must be online (connection to the T1C-DS is needed); depending on the container implementation, a container can work in off-line mode; this is communication with container implementation can optionally be done without accessing a central service.
Last updated
