You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 32 Next »

(Editing is not complete but comment is welcome)

  1. Dependency → Dependency Risk is whenever you have a dependency on something (or someone) else. One simple example could be that the software service might depend on hardware to run on: if the server goes down, the service goes down too. Dependencies can be on events, people, teams, work, processes, software, services, money and pretty much any resource, and while every project will need some of these, they also add risk to any project because the reliability of the project itself is now a function involving the reliability of the dependency. [1] e.g. development limitation
    1. Paper credential: Dependency to paper credential. Just papers credential are accepted.
    2. Impact of EUDI: Unclear how much impact EUDI will have. If it does not go beyond Government based data, our sector will maybe create a parallel ecosystem
    3. Infrastructure: The infrastructure is not ready, separate DI in education in various countries are not ready to join global Edu-Identity
    4. Non-scalable and change-resistant architecture: legacy system are not improvable (dependency on existing infrastructures)
    5. GAFAM Connected Services: These services already established and familiar. Users depend on them and hey find using single id for all service appropriate. 
  2. Intermediaries →  Intermediaries trying to keep their influence 
    1. Translation and evaluation of credentials (i. e. Zentralstelle für ausländisches Bildungswesen (ZAB) in Germany, any translator in home country and foreign)
    2. Issuer in the middle (i. e. Uni-Assisst controlling on-boarding)
  3. Engagement (Governance Rules)→ risk of not being engaged in particular strategic developments and decisions
    1. Other standards and architectures are imposed on us, requiring us to change a lot
      1. GAFAM Tools and Architectures: GAFAMs impose their way (including browsers as "their" tool, interference with their business interests)
    2. Hidden EU standardization process: Most EU standardization is behind closed doors and politicized
    3. EUDI Governance: Unclear how EUDI will be governed in the future (Dependency as well)
  4. Usability → risk of developing systems that do not achieve users "needs and expectations"
    1. User-friendliness: Not good enough user-friendliness makes the wallet-ecosystem fail as a whole

    2. Exclusion Impact: Underestimating the impact of exclusion on certain groups or individuals. There is a risk of underestimating the effort and the cost of ensuring that your identity service does not exclude anyone. Digital exclusion is a common experience and it can happen to anyone. All digital services have an obligation to consider how to minimize barriers for their users, however, there are specific challenges around inclusion for digital identity. There is already an intersection between exclusion from services and the ability to prove identity, and as more evidence traditionally used to verify identity moves online, this may be growing.

      On top of this, where digital identity serves a public sector need, the service typically cannot choose to ignore these barriers because they will need to reach and serve all citizens. Related, providing services that are properly inclusive often requires the creation of support mechanisms, either face-to-face, via video or telephony.  (Not enough availability for all. users and infrastructure  e.g. old people resist )

    3. Complexity vs. Control: Balancing the complexity of the system with user control and ease of use. Identity management involves trust, authentication, privacy, personal information, and security, with complex edge cases and technical standards. A good service should simplify these aspects for users, avoiding overwhelming them with choice or repeated consent requests. However, some users may not care about this, risking not understanding the spectrum of control and convenience. Self-sovereign identity systems, where users hold their identity in a secure digital wallet, offer high levels of control but also greater responsibility. Technical solutions may be less easy for users to understand than centralized systems. [2]

      e.g. so many option and info that make user confused which of them should be deliver which not. Due to complexity of the system may intimidate users to use wallet-based ecosystems. Also due to complexity of the ecosystem NRENs and GEANT might lose their users.
    4. GAFAM:
      1. GAFAM Services: Google and Microsoft offer an identity which connects some of their services together, so it could be well practical for users.
      2. GAFAM Tools: Users are familiar with GAFAM tools and expects something like them. A new model of interface even user-friendly could be rejected by users because they are not similar to GAFAM tools.
    5. Resistance to Change: Resistance to change from stakeholders within the research and education sector, such as institutions, administrators, or users, could impede the successful implementation and adoption of extended identity services. Resistance may stem from factors such as inertia or fear of technology, requiring effective change management strategies to overcome.

    6.  Fragmented solutions (Silos): Providing a user-friendly experience is essential for the adoption and success of identity services. However, the complexity of integrating various systems and platforms within the research and education sector may result in fragmented solutions or "silos," which can negatively impact usability. Inefficient or disjointed user experiences across different platforms or services can lead to frustration and reluctance among users to adopt the identity services. Addressing usability concerns and breaking down silos through cohesive design and integration efforts is necessary to enhance user acceptance and engagement.

  5. Acceptance (Resistance of using the new system? s. also 4.e above):  
    1. Gathering players: Bringing all players to the ecosystem synchronously result in acceptance.  But it is difficult und time-consuming.
    2. Communication with new "VC world": Failing to communicate the new "VC world" to end users and those engaged in the process
      1. Not adequate knowledge: Not adequate knowledge especially in user side about how this model works.

      2. Payment for services: Request for Issuer(Universities), due to their increasing powerful position in the ToIP environment mentioned above, could request an issuance price for high demanded credentials. It could be a barrier of acceptance.

    3. Challenges in Coping with Paper Stability: The transition from traditional paper-based issuance and verification processes to digital identity services may pose challenges in maintaining the stability and reliability that paper documents offer. Paper documents have a long-standing reputation for stability and longevity, and replicating this stability in digital formats, particularly in terms of issuance and verification, may be difficult. Ensuring the durability and longevity of digital identity records while maintaining their integrity and authenticity over time is crucial to overcome this challenge.

    4. Redundant (s. also 7.b below)→ i.e. paper usage coexists with "new" system: fragmented acceptance.
  6. Interoperability (Standards and Protocols) 
    1. Shortage: Lack of Standards and Protocols
    2. Legacy Systems: Ensuring interoperability with existing systems and standards, both within the research and education sector and with external stakeholders, is crucial for the successful integration and adoption of extended identity services. Incompatibilities or difficulties in integration could hinder seamless operation and collaboration across different platforms and organizations.

    3. Agreement Delays: Reaching consensus across many parties with different needs can be time-consuming. Public digital identity programs have large numbers of users, public services, and identity attribute services with different needs and requirements. Creating something that both works for users and meets the needs of a wide variety of services is not a simple undertaking. It can take many years to reach agreement on technical and identity standards, liability, and other policies. For example, the Digital ID and Authentication Council of Canada (DIACC) have spent 4-6 years carefully working to produce a comprehensive framework covering these agreements across all sectors, which are now being tested. The Australian government started the process of creating a framework for agreement in 2015, and in 2021 they have accredited the first private sector organization to be an identity exchange operator. [2]

    4. Incompatibility between protocols and our requirements: Risks due to the fact that when dealing with a dependency, we have to follow a particular protocol of communication, which may not work out the way we want. (Dependency as well)
  7.  Integration
    1. Technical and policy: Some technical and policy compatibility issues cause troubles in integration
    2. Co-existence of "Old" and "New" Systems: The transition to the expanded identity services might not occur smoothly, leading to a prolonged co-existence of traditional methods alongside the new ones. This could result in increased complexity and maintenance efforts for our sector.
    3. Failure to Extend Identity Services: If our community fails to successfully expand our identity services to encompass document presentation, it may create a gap that other market solutions succeed to fill. These alternative solutions might not be tailored to the specific needs of the research and education sector, potentially offering less functionality and security to end-users.
  8. ontopiness ??


References:

[1] https://riskfirst.org/risks/Software-Dependency-Risk

[2] How to control your biggest risks in digital identity — Public Digital

  • No labels