Define security attribute for Datasets?

[redmitry]

Hello,

Beacons implementations provide "securityLevels" in the /configuration endpoint beaconConfigurationSchema.json.
This is OK when all Datasets have the same access level. When we have several datasets, there is no way to express different access levels.
IMHO there must be a

"securityLevel": {
  "type": "string",
  "enum": ["PUBLIC", "REGISTERED", "CONTROLLED"]
}

property in the Dataset., so we can mix CONTROLLED and REGISTERED datasets

D.

[jrambla]

This is definitely an open question.
The securityLevels attribute include, as the documentation explains:
"All access levels supported by the Beacon. Any combination is valid, as every option would apply to different parts of the Beacon."

This is just informative, but not that only softly actionable. It informs the client, e,g, that only registered requests would be accepted, so the client could abstain of sending any query if the user is not authenticated. Is this enough? good to discuss,

When we design v2, we stop at this informative level on purpose. We are hesitating if including a stronger permissions definition in the specification would seem too much complicated and that it would be preferably left to the implementation.

IMU, currently, nothing precludes a beacon to mix datasets with different security levels in the response, isn't it?

[redmitry]

It informs the client, e,g, that only registered requests would be accepted, so the client could abstain of sending any query if the user is not authenticated. Is this enough?

My point is that there could be "PUBLIC" and "CONTROLLED" access simultaneously securityLevels is an array (we should make items unique as an improvement). This way, users couldn't know what datasets are public and what no. Beacon implementers should configure it somewhere anyway. I'd like to have this info in the dataset.

D.

[mbaudis]

In general it will be good if beacons can provide more dataset specific information - which could also be part of a larger "aggregated data" concept (technical and data content).

Edit: So there is no conflict IMO:

• the securityLevels attribute already lists all supported ones which allows the principal shaping / selection of beacons for access
• the /datasets/ payload can be used to get per dataset information (it would have to be added as new parameter, but the schema needs anyway an expansion in direction aggregate content etc.)