Access definitions

[perolavsvendsen]

It is expected that more granular access levels are required going forward. Access block currently:

access:
  asset:
    name: Drogon
  ssdl: # proprietary ssdl stuff
    access_level: internal
    rep_include: true

Some potential user stories:

• As a data owner, I would like to limit general access to some key results while retaining general access to others, so that I can share non-sensitive data only from a specific case
• As a data owner, I would like to exclude specific data objects from specific access groups, to avoid confusion and misunderstandings

A suggestion for an updated access block could be:

access:
  asset:
    name: Drogon
  roles:
    asset: true # always "true" so reduntant?
    license_partner: true
    internal: false
  ssdl: # proprietary ssdl stuff
    access_level: internal
    rep_include: true

This introduces the access.roles which can be expanded on.

Corresponding arguments must be made available in fmu-dataio. Sensible defaults should be set in fmu-dataio (related: #238). It must be intuitive to the end user what accesses he is granting while exporting.

[perolavsvendsen]

Refined to:

Support classifying each outgoing data object as either internal or restricted. Suggested API is:

from fmu.dataio import ExportData

exp = ExportData(
    content="inplace",
    name="MyName",
    access_level="restricted" # <-- proposed new implementation
)

...producing metadata that looks like:

access:
  asset:
    name: MyAsset
  ssdl:
    access_level: "asset" # SSDL/REP - deprecate?
    rep_include: False    # SSDL/REP - deprecate?
  classification: "restricted" # <-- NEW!

• Direct input takes precedence. Second priority is defaults in global_variables.yml. Last fall back is default restricted set in fmu-dataio.
• Add to schema, not required for now.
• Consider consistency check between current ssdl and new classification tag pending possible deprecation.

[perolavsvendsen]

Time to require classification? Have noticed that fmu-dataio for some older versions of RMS still produce metadata without classification.

[perolavsvendsen]

the terminology used in this issue (and elsewhere) is somewhat misleading. We are discussing classification, not access. Even if classification is used for access control later on.

Current state:

• .export() still takes access_ssdl as input argument
• .export() does not take classification as input argument

Suggest:

• Deprecate the access_ssdl argument
• Introduce classification and rep_include arguments (split the previous access_ssdl)

This will give incentive to move away from access_ssdl. Aim is, long-term, to also get rid of rep_include but it is required to keep for now.

Pattern for .export() will then be:

exp.export(mydata, classification="internal", rep_include=False)

...when overriding defaults.

[perolavsvendsen]

#540

[perolavsvendsen]

Sketching in progress: #575

[mferrera]

Based upon discussions we've had since, there is tenuous agreement that this should be handled on the Sumo side rather than at export. There have also been changes made to the way that access is specified initially.