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

[Cinquini, Luca (3880)]

Hi Estani,
	I concur with what Eric said, and to iterate my understanding is that as soon as the data is published with QCL1,
it will be available to registered users. Maybe Bob, Dean or Karl can comment if my understanding is correct or not.
thanks, Luca

On Jul 19, 2010, at 2:52 PM, Eric Nienhouse wrote:

> Hi All,
> 
> We've had a number of discussions on the topic of QC level and data 
> access.  However, I feel we don't yet have a formal definition of the 
> requirements relating to this area.
> 
> I believe it is important to clarify and define the following two QC 
> related areas:
> 
> 1)  Who is the authoritative source of the QC level and how this 
> information is propagated through the system?
> 
> 2)  How does QC level apply to data access policy (eg. access control)?
> 
> I would propose discussing this as a future GO-ESSP telco agenda topic, 
> with the intention we document the outcome.
> 
> Perhaps we can discuss this further via email and work towards capturing 
> the system requirements and related policies in the meanwhile.
> 
> Please note that there are plans to expose the QC Level within the 
> Gateway UI once the data flow is identified.  However, data access 
> control is based upon the group (eg. role) auth-z attribute (such as 
> "CMIP5 Research") and does not currently rely on the QC Level explicitly.
> 
> Thanks,
> 
> -Eric
> 
> 
> Estanislao Gonzalez wrote:
>> Hi Luca,
>> 
>> to sum things up (and correct me Martina/Bryan if I'm wrong):
>> 
>> 1) Published data have QC L1-Data "per se",  and will be available to a 
>> very selected group only (which doesn't seem to be the group you 
>> mention, but I might be wrong).
>> 2) When acquiring QC L2 the data should be accessible to a broader 
>> although still confined group. This check will be performed by DKRZ and 
>> BADC and the information stored somewhere (not sure where though). Where 
>> BADC nor DKRZ have access to all data-nodes, so the information will be 
>> definitely be stored on some "neutral grounds" (CIM DB?).
>> 3) QC L3 == DOI acquired == publication. At this stage data will be  
>> available to any registered user.
>> 
>> If I'm correct, then the security service must check "somehow" the QC 
>> level of the file in order to proceed with the authorization as it is 
>> currently implemented (thus comparing roles).
>> 
>> Any comments anyone?
>> 
>> Thanks,
>> Estani
>> 
>> Cinquini, Luca (3880) wrote:
>> 
>>> Hi Bryan, Martina,
>>> I agree that these issues need to be discussed better, but here are some considerations, which may in some cases only reflect my understanding:
>>> 
>>> 1) we talked about the QC flag for Levels 2 and 3 to be set in the metaphor questionnaire, and be propagated through the atom feed to the gateways
>>> 
>>> 2) I thought that in order not to delay data distribution, as soon as the data has QC level 1 (I.e. It has been processed by the publisher), it will available to registered users of the CMIP5 research and commercial groups
>>> 
>>> 3) At this time there is nothing in the ESG access control model that toes the access attributes to the QC flags.
>>> 
>>> Thanks, luca
>>> 
>>> 
>>> 
>>> 
>>> On Jul 19, 2010, at 7:39 AM, Bryan Lawrence <bryan.lawrence at stfc.ac.uk> wrote:
>>> 
>>> 
>>> 
>>>> Hi Martina
>>>> 
>>>> We definitely need to formalise some of this, so thanks for bringing it 
>>>> up.
>>>> 
>>>> What I had thought we were proposing was that L2 and L3 data have 
>>>> effectively the same restrictions ...
>>>> 
>>>> ... but your fundamental point (I think) is how do we assign the QC, and 
>>>> how does the security software get that information? Ie what is the 
>>>> workflow that needs to exist. We do need to bottom that out.
>>>> 
>>>> Thanks
>>>> Bryan
>>>> 
>>>> On Monday 19 July 2010 13:43:59 Martina Stockhause wrote:
>>>> 
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I had a little discussion with Estani about how the different and
>>>>> changing access constraints on the data depending on their QC levels
>>>>> are realized. It came out that we don't really know.
>>>>> 
>>>>> We have on the one hand the user with a special role e.g.
>>>>> "scientific, non-commercial user", who has access to data on QC L3
>>>>> like every registered user and QC L2 because of his role. On the
>>>>> other hand, the data has a quality attribute (QC Level or QC Flag),
>>>>> which defines the access restriction of the data. For data access a
>>>>> mechanism has to check user role and data attribute, before access
>>>>> is granted or denied.
>>>>> 
>>>>> How does the data get this quality attribute?
>>>>> How is the user role checked against this quality attribute?
>>>>> 
>>>>> For QC L3 we don't need that mechanism, because every registered user
>>>>> has access to all CMIP5 data, but for QC L1 and L2 exist such access
>>>>> restrictions.
>>>>> 
>>>>> Thanks a lot,
>>>>> Martina
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> GO-ESSP-TECH mailing list
>>>>> GO-ESSP-TECH at ucar.edu
>>>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>>> 
>>>>> 
>>>> -- 
>>>> Bryan Lawrence
>>>> Director of Environmental Archival and Associated Research
>>>> (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
>>>> STFC, Rutherford Appleton Laboratory
>>>> Phone +44 1235 445012; Fax ... 5848; 
>>>> Web: home.badc.rl.ac.uk/lawrence
>>>> _______________________________________________
>>>> GO-ESSP-TECH mailing list
>>>> GO-ESSP-TECH at ucar.edu
>>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>> 
>>>> 
>>> _______________________________________________
>>> GO-ESSP-TECH mailing list
>>> GO-ESSP-TECH at ucar.edu
>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>> 
>>> 
>> 
>> 
>> 
>