CIM Issues » CIM Joint Issues

The EU Implementing regulation for accessing metering and consumption data (https://eur-lex.europa.eu/eli/reg_impl/2023/1162/oj) sets out some rules related to permissions getting the access. One of these rules involves sending master data when someone asks for permission to do certain tasks or activities. This master data serves a few purposes: first, it confirms that permission is being requested. Second, it grants permission to the party who wants to access validated historical consumption data as stated in the permission request. Third, it responds to the permission request, letting the requester know if it's valid or not. If the request is valid, it communicates the validation result, but if it's invalid, it indicates that too. Additionally, it informs the concerned party when permission has been successfully established, and it also grants permission to transfer data. So, it's essentially about confirming, granting, responding, communicating results, informing about success, and allowing data transfer as per the permission request.

I agree that this topic is critically important. In the “old days” CIM was inside the utility and one could ignore who supplied data, who can edit the data, and who can access the data. None of these are true statements any longer as we use CIM increasingly for communications outside the utility, including in data space.

I would like to see this issue elevated to “CIM Joint Issues”. I don’t particularly like the idea of creating a new class/specialization that can be associated when necessary to any particular object. Today we might see 10 objects from Europe, 5 objects from the US, etc. Tomorrow there will be more. I would rather see something at the IdentifiedObject level that describes information about data ownership and access. With optional attributes or optional associations, like was done for Name and NameAuthority, one could do the same for access controls, both “permanent” and “temporarily” as this issue raises when access is granted with, for example, and expiration date or a status which could be enabled/disabled.

Issue #6267 entitled “Person and Organization Relationships” has very little information and is two years old without action, but I think if there is a need to update this sort of information we should align this as well with these sorts of data access control objects I am suggesting above.

This was discussed on June 5, 2025 and the urgency was communicated that the proposed solution would be used rather than a more general solution that would allow generical user access.

The proposal seems very different to the access control systems used in commercial systems like SAP or proposed for IEC PAS 61850-90-19 ED1. These systems use a model where a user has a role that has many permissions.

Access control is performed for each user request to read/write data, i.e. an initial step before processing a message request. This is essentially checking for a match between the user/role permissions and the data request
Each permission is a set of { operation, data classes, parameters }

Conceptually permissions refer to classes / identifiers in the main CIM based data.
I'm not sure that permissions per-se belong in CIM but they are data => can be modelled => could be in an ancillary CIM package.

As I understand it, the proposal uses extra associations to a few classes.
But I suspect that what is really needed are extra attributes in the CIM model that can be compared with role permissions. I think at least some of the requests need time-date ranges for the relevant associations, not just for meter readings.

For example:
My understanding of a simple use case related to energy data space.
Customer X gives aggregator Y permission to “read data for customer X for period D1-D2”
(even though they don’t have a CustomerAgreement yet)

Readings has the data
ReadingType lookup data – not personal = no need to access control
MeterReading is associated with UsagePoint = which changes rarely
UsagePoint is associated with the existing CustomerAgreement = which can change = has a date range
CustomerAgreement is associated with Customer = which has a date range

Aggregator Y is associated with Customer X with a new class Permission with 0 to many authorisedReaders
With a date range

So I imagine two queries - a permission check + a data retrieval

SELECT { set of tables/properties AA }
FROM { set of tables/properties BB }
WHERE
(
Requesters identifier = Y
AND Customer identity = X
AND Y is in range [Customer.Permission.authorisedReaders]
AND permission is in date range [D1-D2]
)

And if passed the data retrieval is
SELECT { set of tables/properties A }
FROM { set of tables/properties B }
WHERE
(
Requesters identifier = Y
AND Customer identity = X
AND Y is in range [Customer.Permission.authorisedReaders]
AND CustomerAgreement is associated with Customer for date range [D1, D2]
AND UsagePoint is associated with CustomerAgreement for date range [D1, D2]
AND MeterReading is associated with UsagePoint
AND MeterReading type is active power
AND Reading is associated with MeterReading
AND Readings date IN range [D1, D2]
)