Differences between revisions 1 and 2
Revision 1 as of 2008-06-26 12:26:10
Size: 2956
Editor: kfc
Comment: Created by the PackagePages action.
Revision 2 as of 2010-03-17 13:13:43
Size: 2956
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

Risk Description

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?

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

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:

RiskRightsFramework (last edited 2010-03-17 13:13:43 by localhost)