I have published a research paper "Introducing Privacy Receipts into DLT and eIDAS" in the Journal of ICT Standardization. In short, there is a standards gap how digital identification (e.g., eIDAS2) and wallets standards (e.g., digital wallets, Solid Pods, and Personal Data Spaces) implement privacy principles (e.g., GDPR, ISO/IEC 29100). The individual has no real insights how their personal information is processed when sharing them from their digital wallet. This lack of insights is the motivation for the need of privacy receipts (e.g., Consent, ISO/IEC 27560). Comments are welcome! Same transparency requirement applies to different technologies and industries (e.g., Health, AI, Finance, etc).
The standard describes an authentication scheme including the following features: 1) User needs single unique login credentials to logon to multi-Server setup 2) It offers a two-factor authentication scheme comprising of password as one and the soft token/hardware token as the second factor for authentication 3) The scheme does not require a password table to be maintained at the server 4) The scheme resists various known authentication related attacks
The standard defines methods of out-of-band third-party individual identity attestation and secure conveyance requiring no key storage on the endpoint device.
A biometric lifeless attack is one of the indispensable issues within biometric authentication. There are three major components in liveness detection systems: lifeless attack presentation, liveness detection, and lifeless attack instruments. The lifeless attack presentation is divided into artifact presentation and human-based presentation. The liveness detection method includes subject-based and scenario-based solutions, as well as other attributes such as decision elements, detection patterns, and implementations. The lifeless attack instrument is specified from aspects such as production elements, production types of artifacts, efficacy, etc. This document establishes terms and definitions in the field of biometric liveness detection and identifies characterizations of lifeless attack and liveness detection methods, with analysis on lifeless attack instruments. In addition, this document specifies the liveness detection process, implementation model, and metrics.
The IEEE Standards Association (IEEE SA) pre-standards workstream for Clinical Internet of Things (IoT) data validation and interoperability with blockchain was initiated to determine if a viable standards framework could be established to enable the validation of data generated from a clinical-grade IoT device and shared through the interoperability of blockchain technology. Participants in the workstream were gathered from an IEEE SA workshop held at Johns Hopkins University in Rockville, Maryland in April 2018, and grew to include their network of healthcare and Health-IT ecosystem players, as well as participants in prior IEEE SA efforts in related areas. The workstream commenced in August 2018 and completed in February 2019. Participants in this pre-standards workstream who are the authors of this paper are listed in Appendix A. The pre-standards workstream led to the recommendation of the development of an IEEE SA Standards effort on Clinical IoT data and device interoperability with TIPPSS-Trust, Identity, Privacy, Protection, Safety and Security-in connected healthcare to improve data sharing and healthcare outcomes. The pre-standards workstream team decided that blockchain is not necessary for clinical IoT data and device interoperability and validation, nor does it necessarily meet the robust TIPPSS needs in connected healthcare. The workstream recommendation includes a draft TIPPSS Architectural Framework for Clinical IoT data validation & interoperability, which could include digital ledger technology but does not need to do so. The resulting IEEE Standards Association P2733 working group to develop a standard for Clinical IoT Data and Device Interoperability with TIPPSS kick off meeting is scheduled for July 17, 2019, sponsored by the IEEE SA Engineering in Medicine and Biology Society (EMBS).
Identity assertion, role gathering, multilevel access control, assurance, and auditing are provided by the Biometric Open Protocol Standard (BOPS). An implementation of the BOPS III spec is described, which includes both the software running on the client device as well as the server. Pluggable components are allowed to replace existing components' functionality, accepting integration into current operating environments in a short period of time. A “point-and-cut” mechanism to add the appropriate security to both development and production systems is offered through the BOPS implementation functionality. Homomorphic encryption and a tremendous simplification of the API are also described.
This standard specifies the requirements and methods for verifying the identity of a person equipped with human augmentation technologies. Human augmentation, also known as human enhancement, refers to technologies that add to the human body and enhance human productivity or capability. Recent advancements in many technical areas have led to a large variety of implants, wearables and other technologies that could be classified as human augmentation.
SAML is an XML-based framework for exchanging security information. This security information is expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain. A single assertion might contain several different internal statements about authentication, authorization and attributes. This Recommendation defines a protocol by which clients can request assertions from SAML authorities and get a response from them. This protocol, consisting of XML-based request and response message formats, can be bound to many different underlying communications and transport protocols; SAML currently defines one binding to SOAP over HTTP. In creating their responses, SAML authorities can use various sources of information, such as external policy stores and assertions that were received as input in requests. This Recommendation defines SAML assertions elements, subjects, conditions, processing rules and statements. Additionally, it develops a comprehensive SAML metadata profile that includes associated namespace, common data types, processing rules and signature processing. Several protocol bindings such as SOAP, PAOS (reverse SOAP), HTTP redirect, HTTP POST, among others, are also developed. This Recommendation provides a comprehensive list of SAML profiles such as web browser SSO profile and single logout profile to enable the wide adoption of SAML 2.0 in the industry. Guidelines for authentication context and conformance are also provided.This Recommendation is technically equivalent and compatible with the OASIS SAML 2.0 standard.
