Create data access spec draft ("Customer Data")

[daniel-utilityapi]

This is the specification describing how customer data sources (e.g. utilities) offer data access via API.

• [x] Write summary overview with example
  • Draft: https://github.com/daniel-utilityapi/Customer-Data/blob/main/website/specs/cdsc-wg1-03/overview.md
  • Render: https://daniel-utilityapi.github.io/Customer-Data/specs/cdsc-wg1-03/overview
• [x] Review summary overview and example with working group
• [x] Write specification draft
  • Source: https://github.com/daniel-utilityapi/Customer-Data/blob/issue_24_customer_data/specifications/cdsc-wg1-03.md
  • Render: https://daniel-utilityapi.github.io/Customer-Data/specs/cdsc-wg1-03
• [x] Open pull request for specification draft
• [ ] Review pull request with working group
• [ ] Update based on feedback
• [ ] Merge when consensus is obtained

[halliecramer1]

Two questions: 1) will the Data Scopes have a dictionary to define fields? 2) Related to (1), does usage_intervals tell you the most granular meter data available, e.g. 15 min, and does aggregate_usage allow you to aggregate up to e.g. hourly or is it aggregating across meters?

[greg-flexidao]

There might be a general issue in defining granular access control within OAuth:

• https://auth0.com/blog/on-the-nature-of-oauth2-scopes/
• https://www.aserto.com/blog/oauth2-scopes-are-not-permissions

Discussed during the call extension aims to standardize fine grated scopes within OAuth, but I don't think it still solves the main issues raised by auth0.

Updated options from our call would be:

3. follow rfc9396 (replaces scopes with authorization_details).
4. keep simplified scopes to just resources, that would be relatively high level <service>.<type>.<resource> - i.e. billing.electricity.invoices a) leave out fine grated control from specification (see similar effort and their stand on access control: https://docs.oasis-open.org/cxs/cdp/v1.0/cs01/cdp-v1.0-cs01.html#_access_control) b) create separate specification for access control with i.e. policy-based authorization (i.e. simplified version of https://cloud.google.com/iam/docs/conditions-overview)

[halliecramer1]

Following up on the question from meeting 08-03-2023 - utility should be able to provide interval data related to the mix of delivery or generation associated with a specific tariff.

Types of system mix: generation_breakdown, consumption_breakdown, residual_mix

Tariff mix could include a call which specifies the tariff name and then interval_data

When these are called, the delivery of data should be displayed in the format provided by WG2, which includes information on time interval, units / value by technology / fuel type but assigned proportionally to align with total consumption values in same interval.