[Go-essp-tech] Access control for data with different QC Level

[Martina Stockhause]

Hi, Bryan,

thanks for writing the stuff down. I leave out the political and
implementation issues because there are a lot of people who can comment
on them much better.

Just a question for clarification:
> b) when, where and how, do we set up the "table" which maps 
> access_token_required onto the dataset.
>
> Step 1). we need to record qc information.
>  - the plan is to build a tool for that in September, to be complete by 
> the end of September, and it will export CIM quality documents via an 
> atom feed. It will  be independent of the questionnaire, and folks could 
> deploy it anywhere, even on a data node.
>  (Martina: that can cover the DOI information too.)
>  (I have someone in mind to do the work.)
>   
As I understand, you suggest we have separate QC XML documents in the
data nodes and no ingest or update of the CIM repository, right? This
sounds to me like an intermediate solution. We should hold it small and
easy. So, do we really need an XML for every experiment to create an
AtomFeed out of them afterwards?
Why don't we just keep small lists with DRS experiment name and QC level
at the local data nodes or in the gateway?
Additionally, the security mechanism, which asks for the QC level
attached to certain data, needs to be quick, since the user tries to
start a data download.
 
By the way, I was told by metafor that quality is now a part of several
CIM documents like simulationRun or dataObject but not an independent
document any longer.

Maybe your "someone" has already an idea to discuss.

We could keep a second small list with DRS name and DOI link.

>  - we get qc level one for free (the data can't be published by a data 
> node without being qc level one).
> - given that qc level 2 can only be dealt with at DKRZ, PCMDI and  BADC 
> since it will apply to replicated data, then we only need to deploy the 
> tool there, and gateways will only need to harvest from three places
> - q3 information can only be made available at DKRZ
>   
We can provide a link to additional quality information stored in CERA2
if someone is interested.
> Step 2) the qc information needs to be harvested.
> - this is a gateway issue,  need only to harvest from the three above, 
> plus the QC one at DKRZ. 
>  - It needs to be mapped onto each replica.
>
> Step 3) this information needs to propagate into the PDP (or whatever we 
> are calling the policy decision point, I've lost track of the names).
>
>   
Cheers,
Martina