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.