##Risk Description = Risk Description = ## Detailed description of this risk and its possible implications. ## E.g. If one of the car's tires suffers a puncture, we may run off the road. We expect that the access control framework currently under development by DK-AAI will provide us with: * A single-sign-on solution * Sufficient properties about the roles/tags of the authorised entity * A language to describe the access rights of given roles/tags However, it is unknown if the capabilities of the final framework will meet the requirements for access and rights control defined by the agreements made between internal and external content owners. Also, we are unsure when the framework will be finished and how well it will fit into the architecture of the DOMS, but so far the work presented by DK-AAI looks promising. This risk is actually two-sided, as we also have uncertainties about what requirements the content owners and copyright holders have regarding access and rights control. Hence, we are unsure what means we have for enforcing access and rights control and what exact requirements we need to satisfy in this area. == When to react? == ## When must we respond to the risk? E.g. When the event occurs or already when we see the warning signs? ## E.g. We must react if we hear a hissing sound. We do not consider access and rights control an important part of the DOMS project until we actually need to store data in the DOMS. Hence, we do not need to address this risk until later in the project, and at that time we probably know a lot more about the DK-AAI framework and the requirements, which may mitigate the probability of this risk. == Reaction == ## Detailed description of how to react on the risk and which actions to take, if it is imminent. ## There exists 4 basic reactions: ## 1: Accept the risk. ## 2: Eliminate the cause to the risk. ## 3: Mitigate the probability or the consequence of the risk. ## 4: Delegate the risk to another party, e.g. by outsourcing it or take out insurance for it. ## E.g. We accept the risk and change the tire if we suffer a puncture. We accept this risk for a start and at the time where it becomes relevant, we will be able to mitigate the consequence as we have some power to influence at least some of the requirements defined by the agreements with the content owners. However, our possibilities to influence the access and rights control framework from DK-AAI are probably limited or non-existent. Hence, this risk should not be underestimated as we in the worst-case scenario will be forced to implement our own access and rights control, which will delay the project substantially. == Responsible Persons == The below persons are responsible for continuously monitoring and acting on this risk: ## Add a bullet list with links to the wiki pages of the responsible persons here: ## E.g. ## * [:JohnDoe: John Doe]