The Review of Non-Technical Assumptions in Digital Identity Architectures

Abstract

The literature on digital identity management systems (IdM) is abundant and solutions vary by technology components and non-technical requirements. In the long run, however, there is a need for exchanging identities across domains or even borders, which requires interoperable solutions and flexible architectures. This article aims to give an overview of the current research on digital identity management. We conduct a systematic literature review of digital identity solution architectures and extract their inherent non-technical assumptions. The findings show that solution designs can be based on organizational, business and trust assumptions as well as human-user assumptions. Namely, establishing the trust relationships and collaborations among participating organizations; human-users capability for maintaining private cryptographic material or the assumptions that win-win business models could be easily identified. By reviewing the key findings of solutions proposed and looking at the differences and commonalities of their technical, organizational and social requirements, we discuss their potential real-life inhibitors and identify opportunities for future research in IdM.

Self-Claimed Assumptions in Deep Learning Frameworks: An Exploratory Study

“…We also conducted an industrial survey regarding the integration of agile practices into software architectural assumption management [34]. Bazarhanova and Smolander [3] performed a review on assumptions, while their scope was limited to non-technical assumptions (i.e., interplay between technology and business, inter-organizational aspects, and governance) in digital identity management systems. Xiong et al [31] conducted an exploratory study on assumptions in open source software development.…”

“…After discussion, we decided to classify it into the design category, since the "tensor and variable" category is regarding the tensors and variables themselves instead of using or processing them in certain context. (3) The first author analyzed the remaining 1055 SCAs (out of 3084, 34.21%) following the same process used in the pilot data analysis, i.e., (a) coded the SCAs, (b) compared the codes to generate concepts, and (c) compared the codes and concepts to generate categories in multiple iterations. All the other authors reviewed and discussed the results.…”

Providing Login and Wi-Fi Access Services With the eIDAS Network: A Practical Approach

“…Once the SP Proxy receives the eIDAS-Auth-Res (step 14), it translates it to SPID format. Thus, the SP Proxy prepares the SPID-Auth-Res and sends it back through the user browser to the Login service (steps [15][16]. Finally, the Login Service extracts from the SPID-Auth-Res the value of the spidCode attribute, which contains an eIDAS PersonIdentifier value and checks it against the eIDAS PersonIdentifier value stored in the Polito user profile.…”

“…Content may change prior to final publication. eIDAS application sends the temporary guest account name and password via the user browser to the Cisco WLC (steps [15][16]. Finally, if a match is found among the temporary guest accounts created, then Cisco WLC grants Internet access to the user's device (step 17), otherwise the network access is denied (step 18).…”

“…Some previous works addressed the connection of generic FIWARE-based OAuth 2.0 services to the eIDAS infrastructure [14], or the registration of Erasmus students at visiting universities [15]. In general, as stated in [16], "current and future problem in integrating identity management systems is the myriad of service providers that are not willing (and/or not capable) to implement large modifications in their systems". The solutions addressing this problem should be technically sound, scalable, economically viable, convenient for human users, and should recognize inter-organizational aspects.…”