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

Compare with Current View Page History

« Previous Version 14 Next »

(Edition is not complete)

  1. Dependency 
    1. Dependency Risk is the risk you take on whenever you have a dependency on something (or someone) else. One simple example could be that the software service you write 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]
    2. example: development limitation, just papers credential are accepted
  2. Intermediaries
    1. Intermediaries trying to keep their influence → issuer
  3. Acceptance
    1. Not good enough user-friendliness makes the wallet-ecosystem fail as a whole
    2. Failing to communicate the new "VC world" to end users and those engaged in the process
  4. Engagement (Governance Rules)
    1. Other standards and architectures are imposed on us, requiring us to change a lot
    2. GAFAMs to impose their way (including browsers as "their" tool, interference with their business interests)
  5. Usability
    1. Failing to communicate the new "VC world" to end users and those engaged in the process, if usability is missing, the trust governance cannot be communicated appropriately

    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. e.g. old people resist 

      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. 

    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 
    4. Google and Microsoft offer an identity which connects some of their services together, so it could be well practical for users.
  6. Interoperability (Standards and Protocols) 
    1. lack of Standards and Protocols

    2. Agreement Delays: Reaching consensus across many parties with different needs can be time-consuming.

      Public digital identity programmes 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]

    3. 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.
  7.  Integration
    1. Some technical and policy compatibility issues cause troubles in integration
  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