Weekly OpenADE Meeting Notes - March 7, 2017

Agenda items discussed in the Weekly OpenADE Meeting on March 7, 2017 included Alternative OAuth Flow for ESPI alignment with OAuth 2.0 Specification, considerations on the authorizedPeriod definition, and decisions on Data Custodian scope negotiation and authorization period indications. The Task Force focused on ensuring compliance with current specifications and addressing potential challenges related to data certification testing.

• Meeting Notes
• ESPI
• OAuth
• Data Custodian
• Authorization

whi_ehr Follow

Uploaded on Sep 17, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. Weekly OpenADE Meeting Notes Tuesday, March 7, 2017

2. March 7, 2017 -- Agenda HelpDesk #98 Alternative Oauth Flow for ESPI to align with Oauth 2.0 Specification California CPUC requires OAuth 2.0 authorization_code flow meet Oauth 2.0 RFC 6749 specifications Current Data Custodian Connect My Data Certification test harness currently meets this requirement At question is should the current Data Custodian Connect My Data Certification test harness make Third Party/Data Custodian Scope negotiation optional and thus require changes to the test case requirements and test steps The Task Force decided that the Data Custodian Connect My Data certification test harness MUST provide the ability to be certified using the current Scope Selection Screen flow and the Oauth 2.0 authorization_code flow without accessing the Scope Selection Screen endpoint HelpDesk #98 Is the current definition of authorizedPeriod sufficient? The current definition of authorizedPeriod (found in the ESPI authorization structure) is UINT32, which supports 4,294,967,295 seconds. Some Data Custodians are setting "infinite" expiration periods that exceed this maximum value. The Task Force decided to enforce the current UINT32 definition and ensure Data Custodians use an end date that does not exceed the UINT32 capacity How should a Data Custodian indicate an infinite period? The Task Force decided to indicate a value of 0 in the authorizedPeriod represents an infinite authorization period as part of the ESPI Redline revision.

3. <ns1:entry> <ns1:id xsi:type="ns1:idType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">bed0b17a-6712-40f4-96a1- 487ca6a75244</ns1:id> <ns1:link href="https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Authorization" rel="up" xsi:type="ns1:linkType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> <ns1:link href="https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Authorization/420091" rel="self" xsi:type="ns1:linkType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> <ns1:published xsi:type="ns1:dateTimeType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">2017-02- 08T16:37:40.701Z</ns1:published> <ns1:updated xsi:type="ns1:dateTimeType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">2017-02- 08T16:37:40.702Z</ns1:updated> <ns1:content xsi:type="ns1:contentType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ns0:Authorization xmlns:ns0="http://naesb.org/espi"> <ns0:authorizedPeriod> <ns0:duration>251,915,702,400</ns0:duration> 4,294,967,295 <ns0:start>1486540800</ns0:start> </ns0:authorizedPeriod> <ns0:publishedPeriod> <ns0:duration>251978860800</ns0:duration> <ns0:start>1423382400</ns0:start> </ns0:publishedPeriod> <ns0:status>1</ns0:status> <ns0:expires_at>1486575162</ns0:expires_at> <ns0:scope>FB=1_3_8_13_14_18_19_31_32_35_37_38_39_40_4_15_10_46_47_16_5;IntervalDuration=900_3600;BlockDuration=D aily;HistoryLength=63072000;SubscriptionFrequency=Daily;AccountCollection=1;BR=50036;</ns0:scope> <ns0:token_type>Bearer</ns0:token_type> <ns0:resourceURI>https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Subscription/420091</ns0:resourceURI> <ns0:authorizationURI>https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Authorization/420091</ns0:authoriz ationURI> </ns0:Authorization> </ns1:content> </ns1:entry>

4. March 7, 2017 -- Agenda Future Connect My Data Certification Testing Third Party Connect My Data Certification Tasks Data Custodian Connect My Data Retail Customer Certification Tasks

5. February 28, 2017 -- Agenda Should Certification Test verify Data Custodian only sends data authorized by retail customer? Group agreed the Certification test should verify Data Custodian interval data must meet Scope FB definitions authorized by retail customer. What data should be returned for /resource/Subscription/{subscriptionId}/UsagePoint/{usagePointId}/Meter Reading/ Only MeterReading elements will be returned Should DC CMD Test Harness check non-batch API implementations HelpDesk #98 Alternative Oauth Flow for ESPI to align with Oauth 2.0 Specification California CPUC requires OAuth 2.0 authorization_code flow meet Oauth 2.0 RFC 6749 specifications Current Data Custodian Connect My Data Certification test harness currently meets this requirement At question is should the current Data Custodian Connect My Data Certification test harness make Third Party/Data Custodian Scope negotiation optional and thus require changes to the test case requirements and test steps

6. February 28, 2017 -- Agenda Future Connect My Data Certification Testing Third Party Connect My Data Certification Tasks Data Custodian Connect My Data Retail Customer Certification Tasks

7. CPUC Rule 24: One-Click Has there been a CPUC Final Ruling? Yes. Authorizations must start and finish on the Third Party website CPUC has agreed IOUs can implement authorization via OAuth 2.0 Does CPUC require Data Custodian s to grant multiple Third Parties Access Tokens with One Customer Authorization How should Super Third Party access tokens be assigned Super Third Party is a Third Party that retrieves Energy Usage Information on behalf of their Third Party customer (i.e. Utility API model)

8. CPUC Appendix E DRP Requirements for Solution 3 OAUTH improvements 1. Support authorizations to 2 or more DRPs for the same customer at the same time Needs further investigation and discussion 2. The url that DRP redirects the user to should be the OAuth authorize url (as defined in OAuth 2.0 specification). Requires a new optional Certification Function Block (FB) to verify IOU does not require DRP authorizations to access ESPI ScopeSelectionScreen endpoint 3. The IOU only redirects to authentication interface if needed, then redirects back to the original OAuth authorization url

9. CPUC Appendix E DRP Requirements for Solution 3 4. Authentication interface must be skipped if user already has valid authentication session cookie 5. Authentication interface must be able to allow password resets/reminders and still remain in authorization flow 6. Authentication interface must be able to allow login credentials as authentication fields 7. Authentication interface must have alternative instant authentication for users without logins (account# + zip, etc.)

10. CPUC Appendix E DRP Requirements for Solution 3 8. Best case authorization interface must be 1-click Authorize button 9. Default is all services are pre-selected and customer has to un-select the ones they want to exclude 10.Redirected back to DRP with code after clicking Authorize , no confirmation page on IOU 11.Valid implementation of OAuth 2.0 Code Grant Flow per https://tools.ietf.org/html/rfc6749#section-4.1.

11. CPUC Appendix E DRP Requirements for Solution 3 12.Authorize url meets OAuth 2.0 spec per https://tools.ietf.org/html/rfc6749#section- 4.1.1. Additional value= parameters need to be allowed for IOU DRP specific information Additional optional Function Block testing for DRP support needs to be added to the current CMD certification test suite 13.Be able to handle state parameters, even through authentication interface.

12. CPUC Appendix E DRP Requirements for Solution 3 13. Be able to register multiple redirect_uris with IOUs so that DRPs can have testing/staging/production redirect_uris 15. Be able to handle re-authorization for new code grant if DRP has lost previous code or access_token Requires addition of test script to confirm Data Custodian meets above requirement. 16. Be able to handle a user declining to authorize a DRP in both authentication and authorization interface. 17. Be able to redirect errors back to the DRP per https://tools.ietf.org/html/rfc6749#section-4.1.2.1

13. Query Parameters Atom published -- represents the time stamp when the containing entry was created updated represents the time stamp when the containing entry was changed Original Intent Required: query using published_min,max allows search of IntervalBlocks that contain intervals between min and max Does this require correct values for published in atom or just that the query parameters are properly interpreted?

14. Query Parameter Requirements From GreenButtonAuthorization.docx

15. Current Implementations LH published timestamp is the end of the first interval in the IntervalBlock PGE published timestamp is the moment of creation of the XML result Query parameters published_min/max must be interpreted in the context of the IntervalBlocks which is the data actual being sought by the query Certification Test Algorithm: 1. Test Harness performs an authorization on the test account 2. Test account must have 4 or more interval blocks of data 3. Test Harness does GET on resourceURI returning subscription with n IntervalBlocks 4. Test Harness does GET on resourceURI with 1. published_min equal to the IntervalBlock.start time of the 2nd IntervalBlock returned in step 3 2. published_max equal to the IntervalBlock.start time (n-1)th IntervalBlock returned

16. Initial Third Party Test Requirements very rough [FB_20] Common Common configuration data exchange [FB_21] Connect My Data Support Application Info request or other similar from FB_03 Support notification reception [FB_22] Security and Privacy Classes Support the TP version of FB_13 (relaxes from TLS 1.2 to TLS 1.1, I don t know if there is anything else different). [FB_23] Authorization and Authentication Perform the client side of OAuth [FB_24] Request Bulk UsagePoints If supported, receive a Notification and to an bulk GET or SFTP GETALL [FB_25] Request Partial Update Data No initial tests required [FB_26] Properly Respond to Various Bad or Missing Data Perform authorization, TP performs GET of resourceURI, provide several examples of bad data [FB_42] Core REST Services No initial tests required

17. Older or other slides Will build deck with new content over time.

18. Topics Service Request 95 Green Button Download My Data Gas Function Block [FB_10] only allows "therms" UOMType = 169 Permit therms, joules, ft3, m3 expand acceptance of test Optionally if you have volume, add MeterReading, ReadingType, and IntervalBlock for convervion factor history Service Request 96 Green Button Download My Data Water Function Block [FB_11] only allows UOMType = 128 (US gl (US Gallons) Permit US Gallons, ft3, and m3 expand acceptance of test Service Request 97 Update UsagePoint for 61968-9 2nd edition elements Service Request 83 including Function Block for optional customer info (service point address, etc.) retailcustomer.xsd Updated schema espiderived.xsd LSE, MDMA, MSP identification Sub-LAP and LCA planning bus and a market operations bus? Accept API and FBs Generate Test Requirements espiderived.xsd Updated UsagePoint Populating UsageSummary bill elements Query Parameter Testing for FB_37 Testing Requirements for Third Parties Tariff Model Resource

19. Support of Aggregate References Sub-LAP (associated with parent LAP) ApnodeType=LAP(Load Aggregation Point) as a child of aggregateNodeRef LAP Load Aggregation Point AnodeType=ALR(Aggregate Load Resource) LCA - Load Capacity Area ApnodeType=CA(Control Area) planning bus ApnodeType=BUS market operations bus ApnodeType=BUS

20. CIM UML Model of Aggregates class Aggregate... class Aggregate... enumeration MktDomain:: AnodeType class AggregateNode class AggregateNode MktDomain:: AnodeType +RTO MktOrganisation RTO 1 SYS RUC LFZ REG AGR POD ALR LTAC ACA ASR ECA RTO +RTO 0..1 RUCZone RUCZone +RTO 1 +AggregateNode 0..* IdentifiedObject LoadAggregationPoint LoadAggregationPoint AggregateNode AggregateNode + anodeType: AnodeType [0..1] + endEffectiveDate: DateTime [0..1] + qualifASOrder: Integer [0..1] + startEffectiveDate: DateTime [0..1] MarketRegion MarketRegion 0..1 +AggregateNode class Apnode class Apnode +AggregateNode 0..* 0..* +AggregateNode enumeration MktDomain:: ApnodeType MktDomain:: ApnodeType 0..* +CnodeDistributionFactor IdentifiedObject AG CPZ DPZ TH SYS CA DCA GA GH EHV ZN INT BUS +RegisteredResources +RegisteredResource 0..* CnodeDistributionFactor CnodeDistributionFactor 0..* +Pnode PowerSystemResource MarketCommon:: RegisteredResource +RegisteredResource + factor: Float [0..1] + podLossFactor: Float [0..1] IdentifiedObject Pnode +Pnode MarketCommon:: RegisteredResource Pnode 0..* 0..* 0..1 +Pnodes 0..* 0..* +CnodeDistributionFactor +MktConnectivityNode RegisteredGenerator RegisteredGenerator RegisteredLoad RegisteredLoad AggregatedPnode AggregatedPnode +MktConnectivityNode 1 0..* ConnectivityNode MarketOpCommon:: MktConnectivityNode +MktConnectivityNode MarketOpCommon:: MktConnectivityNode IndividualPnode IndividualPnode RegisteredInterTie RegisteredInterTie 0..1 1 +IndividualPnode +MktConnectivityNode 0..1

21. espiderived.xsd extension of UsagePoint

22. Sample XML <?xml version="1.0" encoding="UTF-8"?> <UsagePoint xmlns="http://naesb.org/espi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://naesb.org/espi espiDerived.xsd"> <ServiceCategory> <kind>1</kind> </ServiceCategory> <pnodeRefs> <pnodeRef> <apnodeType>BUS</apnodeType> <ref>reference to a bus</ref> </pnodeRef> </pnodeRefs> <aggregateNodeRefs> <aggregateNodeRef> <anodeType>ALR</anodeType> <ref>reference to an aggregate load resource</ref> <pnodeRef> A pnode that is a bus reference A LAP Aggregate with a SUB-LAP pnode reference <apnodeType>LAP</apnodeType> <ref>reference to an sub aggregated load</ref> </pnodeRef> </aggregateNodeRef> </aggregateNodeRefs> </UsagePoint>

23. Pnodes and AggregateNodes <pnodeRefs> <pnodeRef> <apnodeType>LAP</apnodeType> <ref>https://fubar.com/espi/1_1/resources/pnodes/aggregatePnodes/12345656</ref> </pnodeRef> </pnodeRefs> <aggregateNodeRefs> <aggregateNodeRef> <anodeType>SYS</anodeType> <ref>https://fubar.com/espi/1_1/resources/aggregateNodes/LoadAggregationPoints/2468ef2</ref> </aggregateNodeRef> </aggregateNodeRefs>

24. Some DC Procedures PGE: http://www.pge.com/en/myhome/addservices/sh aremydata/authorized/api/testing/index.page? http://www.pge.com/en/myhome/addservices/sh aremydata/authorized/getstarted/index.page? <<need to collect from SDG&E, SCE, and LondonHydro>>

25. Pnode/AggregationPoints from CIM Model class AggregateNode class AggregateNode +RTO MktOrganisation RTO 1 RTO +RTO 0..1 RUCZone RUCZone +RTO 1 +AggregateNode 0..* IdentifiedObject LoadAggregationPoint LoadAggregationPoint AggregateNode AggregateNode + anodeType: AnodeType [0..1] + endEffectiveDate: DateTime [0..1] + qualifASOrder: Integer [0..1] + startEffectiveDate: DateTime [0..1] MarketRegion MarketRegion 0..1 +AggregateNode +AggregateNode 0..* 0..* +AggregateNode 0..* +CnodeDistributionFactor IdentifiedObject +RegisteredResources +RegisteredResource 0..* CnodeDistributionFactor CnodeDistributionFactor 0..* +Pnode PowerSystemResource MarketCommon:: RegisteredResource +RegisteredResource + factor: Float [0..1] + podLossFactor: Float [0..1] IdentifiedObject Pnode +Pnode MarketCommon:: RegisteredResource Pnode 0..* 0..* 0..1 +Pnodes 0..* 0..* +CnodeDistributionFactor +MktConnectivityNode RegisteredGenerator RegisteredGenerator RegisteredLoad RegisteredLoad AggregatedPnode AggregatedPnode +MktConnectivityNode 1 0..* ConnectivityNode MarketOpCommon:: MktConnectivityNode +MktConnectivityNode MarketOpCommon:: MktConnectivityNode IndividualPnode IndividualPnode RegisteredInterTie RegisteredInterTie 0..1 1 +IndividualPnode +MktConnectivityNode 0..1

26. UsagePoint Associations that will add the needed elements class CustomersOverview class CustomersOverview IdentifiedObject Metering::UsagePoint Metering::UsagePoint + isSdp: Boolean [0..1] + isVirtual: Boolean [0..1] + phaseCode: PhaseCode [0..1] + grounded: Boolean [0..1] + servicePriority: String [0..1] + serviceDeliveryRemark: String [0..1] + estimatedLoad: CurrentFlow [0..1] + checkBilling: Boolean [0..1] + ratedCurrent: CurrentFlow [0..1] + nominalServiceVoltage: Voltage [0..1] + ratedPower: ActivePower [0..1] + outageRegion: String [0..1] + readCycle: String [0..1] + readRoute: String [0..1] + amiBillingReady: AmiBillingReadyKind [0..1] + connectionState: UsagePointConnectedKind [0..1] + minimalUsageExpected: Boolean [0..1] enumeration MktDomain:: AnodeType MktDomain:: AnodeType SYS RUC LFZ REG AGR POD ALR LTAC ACA ASR ECA 0..* 0..* +UsagePoints +UsagePoints +AggregateNodes 0..* +Pnode 0..1 IdentifiedObject IdentifiedObject ReferenceData::AggregateNode ReferenceData::AggregateNode ReferenceData::Pnode ReferenceData::Pnode +Pnode +AggregateNode + anodeType: AnodeType [0..1] + endEffectiveDate: DateTime [0..1] + qualifASOrder: Integer [0..1] + startEffectiveDate: DateTime [0..1] + endEffectiveDate: DateTime [0..1] + isPublic: Boolean [0..1] + startEffectiveDate: DateTime [0..1] 0..* 0..*

27. AnodeTypes for Aggregate Nodes - SYS - System Zone/Region; - RUC - Reliability Unit Commitment Zone; A specialized class of type AggregatedNode type. Defines RUC Zones. A forecast region represents a collection of Nodes for which the Market operator has developed sufficient historical demand and relevant weather data to perform a demand forecast for such area. The Market Operator may further adjust this forecast to ensure that the Reliability Unit Commitment produces adequate local capacity procurement. - LFZ - Load Forecast Zone; - REG - Market Energy/Ancillary Service Region; - AGR - Aggregate Generation Resource; - POD - Point of Delivery; - ALR - Aggregate Load Resource; - LTAC - Load Transmission Access Charge (TAC) Group; - ACA - Adjacent Control Area - ASR - Aggregated System Resource - ECA - Embedded Control Area LoadAggregatinPoint (ALR?), SubLoadAggregationPoint (ECA?), ICAP or LocalCapacityArea (SYS?) are in this list or need to be explicitly added.

28. Resulting XML Schema For UsagePoint Enhancements XML XMLSchema (at end of UsagePoint)

29. RetailCustomer Model Identities for Rule 24 class RetailCustomer class RetailCustomer class RetailCustomer class RetailCustomer Enumeration PaymentMetering: :SupplierKind PaymentMetering: :SupplierKind PaymentMetering::ServiceSupplier PaymentMetering::ServiceSupplier + kind: SupplierKind [0..1] + issuerIdentificationNumber: String [0..1] utility retailer other lse mdma msp Meter Multipliers class RetailCustomer class RetailCustomer class RetailCustomer class RetailCustomer Enumeration Metering:: MeterMultiplierKind Metering:: MeterMultiplierKind +Meter Metering::Meter Metering::Meter kH kR kE ctRatio ptRatio transformerRatio + formNumber: String [0..1] Metering::MeterMultiplier Metering::MeterMultiplier 0..1 0..* + kind: MeterMultiplierKind [0..1] + value: Float [0..1] +MeterMultipliers

30. Retail Customer class RetailCustomer class RetailCustomer IdentifiedObject Common:: OrganisationRole IdentifiedObject IdentifiedObject Common:: OrganisationRole +Roles Common::Document Common::Document Common::Organisation Common::Organisation +Organisation 0..* + type: String [0..1] + authorName: String [0..1] + createdDateTime: DateTime [0..1] + lastModifiedDateTime: DateTime [0..1] + revisionNumber: String [0..1] + electronicAddress: ElectronicAddress [0..1] + subject: String [0..1] + title: String [0..1] + docStatus: Status [0..1] + status: Status [0..1] + comment: String [0..1] + streetAddress: StreetAddress [0..1] + postalAddress: StreetAddress [0..1] + phone1: TelephoneNumber [0..1] + phone2: TelephoneNumber [0..1] + electronicAddress: ElectronicAddress [0..1] 0..1 Common::Agreement Common::Agreement PaymentMetering::ServiceSupplier PaymentMetering::ServiceSupplier + signDate: Date [0..1] + validityInterval: DateTimeInterval [0..1] + kind: SupplierKind [0..1] + issuerIdentificationNumber: String [0..1] Customers:: CustomerAccount Customers:: CustomerAccount Customers::Customer Customers::Customer Customers:: CustomerAgreement Customers:: CustomerAgreement + kind: CustomerKind [0..1] + specialNeed: String [0..1] + pucNumber: String [0..1] + status: Status [0..1] + priority: Priority [0..1] + locale: String [0..1] deprecated + vip: Boolean [0..1] + billingCycle: String [0..1] + budgetBill: String [0..1] + lastBillAmount: Money [0..1] + loadMgmt: String [0..1] + isPrePay: Boolean [0..1] + shutOffDateTime: DateTime [0..1] +CustomerAgreements 0..* +CustomerAgreements 0..* +PricingStructures0..* +DemandResponsePrograms 0..* Customers:: PricingStructure Customers:: PricingStructure Metering::DemandResponseProgram Metering::DemandResponseProgram IdentifiedObject Common::Location Common::Location + type: String [0..1] + mainAddress: StreetAddress [0..1] + secondaryAddress: StreetAddress [0..1] + phone1: TelephoneNumber [0..1] + phone2: TelephoneNumber [0..1] + electronicAddress: ElectronicAddress [0..1] + geoInfoReference: String [0..1] + direction: String [0..1] + status: Status [0..1] IdentifiedObject Assets::Asset Assets::Asset + type: String [0..1] + utcNumber: String [0..1] + serialNumber: String [0..1] + lotNumber: String [0..1] + purchasePrice: Money [0..1] + critical: Boolean [0..1] + electronicAddress: ElectronicAddress [0..1] + lifecycle: LifecycleDate [0..1] + acceptanceTest: AcceptanceTest [0..1] + initialCondition: String [0..1] + initialLossOfLife: PerCent [0..1] + status: Status [0..1] Work:: Work:: WorkLocation WorkLocation Assets:: AssetContainer Assets:: AssetContainer Customers::ServiceLocation Customers::ServiceLocation + accessMethod: String [0..1] + siteAccessProblem: String [0..1] + needsInspection: Boolean [0..1] +ServiceLocation 0..1 +UsagePoints Metering:: UsagePoint Metering:: UsagePoint 0..* Metering::EndDevice Metering::EndDevice + isVirtual: Boolean [0..1] + isPan: Boolean [0..1] + installCode: String [0..1] + amrSystem: String [0..1] Metering::Meter Metering::Meter +Meter +MeterMultipliers + formNumber: String [0..1] Metering::MeterMultiplier Metering::MeterMultiplier 0..1 0..* + kind: MeterMultiplierKind [0..1] + value: Float [0..1]

31. class RetailCustomer class RetailCustomer Minor Classes and Enums Compound Common::Status Enumeration Compound Common::TownDetail Common::Status Customers::CustomerKind Customers::CustomerKind Common::TownDetail + value: String [0..1] + dateTime: DateTime [0..1] + remark: String [0..1] + reason: String [0..1] residential residentialAndCommercial residentialAndStreetlight residentialStreetlightOthers residentialFarmService commercialIndustrial pumpingLoad windMachine energyServiceSupplier energyServiceScheduler internalUse other + code: String [0..1] + section: String [0..1] + name: String [0..1] + stateOrProvince: String [0..1] + country: String [0..1] Compound Common::Priority Compound Common::Priority Common::StreetDetail Common::StreetDetail + rank: Integer [0..1] + type: String [0..1] + justification: String [0..1] + number: String [0..1] + name: String [0..1] + suffix: String [0..1] + prefix: String [0..1] + type: String [0..1] + code: String [0..1] + buildingName: String [0..1] + suiteNumber: String [0..1] + addressGeneral: String [0..1] + addressGeneral2: String [0..1] + addressGeneral3: String [0..1] + withinTownLimits: Boolean [0..1] Enumeration PaymentMetering: :SupplierKind PaymentMetering: :SupplierKind utility retailer other lse mdma msp Compound Assets::AcceptanceTest Assets::AcceptanceTest + type: String [0..1] + success: Boolean [0..1] + dateTime: DateTime [0..1] Compound Enumeration Metering:: MeterMultiplierKind Common::TelephoneNumber Common::TelephoneNumber Metering:: MeterMultiplierKind Compound Assets::LifecycleDate Assets::LifecycleDate + countryCode: String [0..1] + areaCode: String [0..1] + cityCode: String [0..1] + localNumber: String [0..1] + extension: String [0..1] + dialOut: String [0..1] + internationalPrefix: String [0..1] + ituPhone: String [0..1] kH kR kE ctRatio ptRatio transformerRatio + manufacturedDate: Date [0..1] + purchaseDate: Date [0..1] + receivedDate: Date [0..1] + installationDate: Date [0..1] + removalDate: Date [0..1] + retiredDate: Date [0..1] Compound Compound Common:: ElectronicAddress Common::StreetAddress Common::StreetAddress Common:: ElectronicAddress + streetDetail: StreetDetail [0..1] + townDetail: TownDetail [0..1] + status: Status [0..1] + postalCode: String [0..1] + poBox: String [0..1] + lan: String [0..1] + mac: String [0..1] + email1: String [0..1] + email2: String [0..1] + web: String [0..1] + radio: String [0..1] + userID: String [0..1] + password: String [0..1]

32. espiderived: UsagePoint current Extends UsagePoint based on newer CIM model: iec61970cim17v06a_iec61968cim 12v10_iec62325cim03v02 Backwards compatibility assured by adding new elements to end of list.

33. billLastPeriod billLastPeriod The total bill for the billing period billLastPeriod = costAdditionalDetailLastPeriod.LineItem.amount costAdditionalLastPeriod Deprecate and if present, should have the same value of billLastPeriod if you populate the costAdditionalDetailLastPeriod, then costAdditionalLastPeriod would be expected to have the total IntervalReading.cost Provided if FB_12 is selected and should probably be consistent with costAdditionalDetailLastPeriod.LineItem.amount records for which these costs pertain but this is not guaranteed billLastPeriod = costAdditionalDetailLastPeriod.LineItem.amount Should always add up to billLastPeriod. If the details provided are not complete, a record other should be included to make up the difference and indicate that all billing details have not been provided. If no amounts are presented in this detail, there is no need for a compensating other record to add up to billLastPeriod

34. Query Parameters There was a significant discussion, led by Partha, about how the depth query parameter should work. During the call we accessed the Implementation Agreement and discovered the only documentation of the query parameters is a list of the query parameter keywords. The group agreed we need to document how the parameters work and the expected format they should contain. For example, the date query parameters (published-min, published-max, updated-min, and updated-max) need to indicate they are to be UTC Z time formats and not epoch time. As a result of the two above items, additional test need to be added to FB_37 to: Ensure query elements containing epoch time generate a 400 response Ensure query elements containing ALL generate a 400 response Ensure responses match requested max & depth values

35. Topics Value mapping for TOU and CPP and ConsumptionTier sftp for Batch/Bulk/{bulkId} Is there a user ? sftp://user@localhost/DataCustodian/espi/1_1/resource/Batch/Bulk/{bulkId} Suggestion fixed user= GreenButton so no PII in sftp startup Alternative let DC provide arbitrary uuid in the notification Conclusion: the DC chooses the user and includes it in the notificationUri where the TP gets it for use in the exchange. Target Firm Up end of July: Retailcustomer.xsd Need to define function blocks -- Potentials: FB_X1 Minimal that only provides actual IDs and UsagePoints FB_X2 Service Location Contents Name and Addresses and location, No fb needed now End device No fb needed now Pricing Structure FB_X3 Account data for DMD access Access Tokens Access tokens to access? Individual with access_token, bulk with client_access_token URI in Authorization customerResourceUri needed in OAuth authorization response and Authorization xml structure customerResourceUri in client access Authorization would be batch/BulkRetailCustomerInfo Test requirements If Scope has RetailCustomer function blocks, then Verify Authorization has customerResourceUri Verify Oauth response has customerResourceUri Verify client_access_token works for esource/Batch/BulkRetailCustomerInfo Verify access_token works for resource/RetailCustomer Additional attributes Move in move out use CustomerAgreement.validityInterval Target Firm Up List end of July: UsageSummary.CostAdditionalDetail.itemKind Tax, Other, ThirdParty energy provider fee, ThirdParty energy provider usage, Credit, Discount, Usage, Demand, TOU, incentive, informational, Customer Charge, Energy Charges, Supply Charges, Distribution Charges, Transmission Charges, Generation Charges, State Gross Receipts Tax, State Tax Adjustment, Administrative Charge, Ancillary Charge, Balancing Service Charge, Working Capital Charge, Purchased Generation Adjustment, Cost Adjustment, Service Location Distribution Charge, Other, Minimum charge, Tier Charge, Adjustment Charge, Program Charge/Credit, Amount Paid, Power Factor adjustment, DWR energy credit (calculation and credit value), UUT exemption status, State Tax, Local Tax, Transmission Charges, Distribution Charges, Nuclear Decommissioning Charges, Public Purpose Programs Charges, Franchise Fee, Generation Charge Will finish consolidation of list and review OAuth login requirements for the testing

36. ItemKind Simplified 1 2 3 Energy Generation Fee. A charge for generation of energy. Energy Delivery Fee. A charge for delivery of energy. Energy Usage Fee. A charge for electricity, natural gas, water consumption Administrative Fee. A fee for administrative services. Tax. A local, state, or federal energy tax. Energy Generation Credit. A credit, discount or rebate for generation of energy. Energy Delivery Credit. A credit, discount or rebate for delivery of energy. Administrative Credit. A credit, discount or rebate for administrative services. Payment. A payment for a previous billing. Information. An informational line item. 4 5 6 7 8 9 10

37. TOU, CPP, ConsumptionTier Code Descriptions TOU, CPP, ConsumptionTier are integers in ReadingType/IntervalReading What does 3 mean? Draft Solution: Provide an optional table in UsagePoint that provides the code, name, and description of the values of TOU and CPP when used underneath it.

38. UsagePoint.ProgramMappings <UsagePoint> </UsagePoint> <ServiceCategory> <kind>1</kind> </ServiceCategory> <programIdMappings> <programIdMapping> </programIdMapping> <programIdMapping> </programIdMapping> </programIdMappings> <tOUorCPPorConsumptionTier>tou</tOUorCPPorConsumptionTier> <code>1</code> <name>Summer Peak</name> <tOUorCPPorConsumptionTier>tou</tOUorCPPorConsumptionTier> <code>2</code> <name>Winter Peak</name>

39. RetailCustomer Architecture API GET .../resource/Batch/RetailCustomer/{id} GET .../resource/CustomerInformation/{id} GET .../resource/CustomerInformation/{id}/RetailCustomer/{id}/CustomerAccount/{id}/CustomerAgreement GET /resource/Customer/{id} GET .../resource/CustomerAgreement/{id} GET .../resource/Batch/BulkRetailCustomerInfo/{id} PG&E proposal Current Architecture

40. Large Organization Use Case Corporate Authorizes EMS Co Resource Example EMS Co Web Account Safeway Company Customer SF Regional Mgr, Oakland RM Customer Account Individual Stores Service Agreement Gas service, Electrical service Service Point Usage Points There is sometimes an authority that can authorize a large number of individual accounts, e.g. gsa/McDonalds, where the individual accounts may be franchised or otherwise owned/managed yet the individual accounts have the responsibility to maintain the utility account and pay the bills.

41. Query Parameters There was a significant discussion, led by Partha, about how the depth query parameter should work. During the call we accessed the Implementation Agreement and discovered the only documentation of the query parameters is a list of the query parameter keywords. The group agreed we need to document how the parameters work and the expected format they should contain. For example, the date query parameters (published-min, published-max, updated-min, and updated-max) need to indicate they are to be UTC Z time formats and not epoch time. As a result of the two above items, additional test need to be added to FB_37 to: Ensure query elements containing epoch time generate a 400 response Ensure query elements containing ALL generate a 400 response Ensure responses match requested max & depth values Jerry Yip has some additional itemKind elements he wants to discuss during next week s OpenADE Task Force call, which he will provide in a follow up e-mail. Jerald Pinnecker wants to discuss subscriptions during next week s OpenADE Task Force call. Presently they send subscription data to a Third Party when they register and he wants to know how that data is then tied to the access token when the Third Party completes the authorization request. Additionally, he wants to know who the Third Party is supposed to use the access token.

42. OAuth Authorization Failure Mode Usage Scenario: 1. TP redirect user to DC scope selection. 2. User approves TP and scope. 3. DC redirects user to TP with scope parameter. 4. TP redirects users to DC's OAuth /authorize endpoint with scope and client_id parameters. 5. DC redirects back to TP redirect_uri with OAuth code parameter. 6. TP makes a request to DC's OAuth /token endpoint with the code. 7. DC responds with an access_token and refresh_token. 8. TP's server crashes and doesn't save either token. How is the TP supposed to get new tokens? In normal OAuth, you simply redirect the user back to the OAuth /authorize endpoint, the user approves access again and gets redirected back with a new code. However, at least in one current implementation, the TP has to redirect the user to the scope selection screen, where the user will be told that they have already authorized the TP with no option to re-authorize. In order to get new tokens, the use manually has to cancel authorization, which causes them to get redirected to the main website. Then the user manually has to go back to the scope selection screen and authorize the TP again. This re-authorization process is not ideal because it requires us training the user to cancel-then-manually-go-back- and-reauthorize, which is a very confusing and complex process and doesn't redirect the user back to the TP after cancellation. Two possible solutions: 1. On the DC's scope selection interface, have a re-authorize button if the user has already authorized the TP. 2. Allow TP's to redirect the user to OAuth's /authorize endpoint with the same scope, and have the DC ask for re-authorization at that point. Option 1 is better for GBCMD, in my opinion, because it also allows for the scenario where the TP loses the scope parameter, too. Option 2 is the more technically correct OAuth procedure. All other OAuth services I can think of do Option 2, but they also don't require a pre-defined scope parameter for the /authorize endpoint (so there's nothing to lose).

43. GET Subscription w/wo query parameters Default required behaviors Problem: The amount of data that is in a: GET /Batch/Subscription/{subscriptionId} can potentially be very large. What is the obligation of a DC when that message is received without query parameters? What about the desire of some DC s to provide only a fixed size response of say X months? What about when a subscription contains 1/10/1000 UsagePoints? Alternatives 1) Requires date range in GET /Batch/Subscription/{subscriptionId} DC responds with 202 if data is too large to return right away Returns with notification when data is ready and can provide query distinguished URIs 2) DC decides maximum depth to return when no query parameters TP may get whole history (from scope parameter HistoryLength) or may get less. 3) Term in Scope for default GET Subscription depth The scope can indicate for the specific subscription what the default length is. The DC decides during scope selection what to include in the offered scopes. Solution: Publish min/max required on resource/Batch/XXXXX APIs

44. Discussion of responses to requests for large data sets Given: It's possible for a subscription to have small or enormous at data sets There GB CMD applications on the market that don't require query parameters Query parameters are specified and the Min and Max public support required for our minimum set If you have or don't have query parameters the third party is likely always to ask the first time for everything We agreed in a face-to-face that we were going to support a response of 202 when large off-line data sets are requested In a response asking for everything it should be the discretion of the data custodian to determine what the largest response it's willing to give Some data custodians want to define a fixed maximum size for any request An empty response (feed with no resources) implies no more data Therefore: Query parameters should remain optional in any given request Absence of query parameters means everything this means all available data that DC is willing to provide 202 is a valid response for ./Batch/ followed by a notification when data is ready The DC decides how much a maximum data response to an API request will be A TP that receives less than anticipated can ask for older data. If he gets back an empty feed, he has it all. Note: that if there is a gap in the data and he asks for the gap, he may get empty feed but there may be more data behind it.

45. CIM Tariff Model class TariffProfile class TariffProfile Document Customers:: PricingStructure Customers:: PricingStructure +PricingStructures 0..* +Tariffs 0..* Document Customers:: Tariff IdentifiedObject Metering:: ReadingType Customers:: Tariff Metering:: ReadingType Charges associated with time threshholds Charges associated with value threshholds +Tariffs 0..* +ReadingType 0..1 +TariffProfiles 0..* Document +TariffProfiles +TariffProfiles TariffProfile TariffProfile 0..* 0..* + tariffCycle: String [0..1] +ConsumptionTariffIntervals +TimeTariffIntervals +ConsumptionTariffIntervals 0..* 0..* 0..* TimeTariffInterval TimeTariffInterval ConsumptionTariffInterval ConsumptionTariffInterval +TouTariffIntervals +ConsumptionTariffIntervals + sequenceNumber: Integer [0..1] + startTime: Time [0..1] + sequenceNumber: Integer [0..1] + startValue: Float [0..1] 0..* 0..* 0..* 0..* +TimeTariffIntervals +ConsumptionTariffIntervals Compound AccountingUnit IdentifiedObject Charge AccountingUnit Charge +Charges +Charges + value: Float [0..1] + energyUnit: RealEnergy [0..1] + monetaryUnit: Currency [0..1] + multiplier: UnitMultiplier [0..1] + kind: ChargeKind [0..1] + fixedPortion: AccountingUnit [0..1] + variablePortion: PerCent [0..1] 0..* 0..* +ParentCharge 0..1 +ChildCharges 0..*

46. Additional Information for UsageSummary.CostAdditionalDetail Add an enumeration tag to lineitem to indicate what kind of charge it is itemKind Tax TOU Demand ThirdParty energy provider fee ThirdParty energy provider usage

47. Solutions to Add Customer Account Numbers Make non- obfuscatedId Add link Extend each Class with IdentifiedObject.name Add Atom Extension

48. Account/Agreement Topology

49. Separation of PII containing Resource RetailCustomer from Subscription* PII Containing information Anononymous EUI Subscription Customer CustomerAccount UsagePoint Customer Agreement Normal ESPI Resources ServiceLocation PostionPoint Key Authorization ServiceSupplier New Resource EndDeviceAsset PricingStructure Existing Resource *This data structure is to be developed on an aggressive schedule based on HelpDesk issue #83 and PAP10 NAESB Std REQ.18. No single API request can retrieve both PII and Anonymous data Non-Resource Class

50. class CustomerProfile class CustomerProfile OrganisationRole Customers::Customer Need to determine which are IdentifiedObjects -> resources {root} Model + kind: CustomerKind [0..1] + specialNeed: String [0..1] + pucNumber: String [0..1] + status: Status [0..1] + priority: Priority [0..1] + locale: String [0..1] ::IdentifiedObject + description: String [0..1] + mRID: String [0..1] + name: String [0..1] Document Customers::CustomerAccount + billingCycle: String [0..1] + budgetBill: String [0..1] ::Document + createdDateTime: DateTime [0..1] + lastModifiedDateTime: DateTime [0..1] + revisionNumber: String [0..1] + status: Status [0..1] ::IdentifiedObject + description: String [0..1] + mRID: String [0..1] + name: String [0..1] +CustomerAgreements +Customer Agreement +CustomerAccounts Customers::CustomerAgreement 1 0..* + loadMgmt: String [0..1] ::Agreement + signDate: Date [0..1] + validityInterval: DateTimeInterval [0..1] ::Document + createdDateTime: DateTime [0..1] + lastModifiedDateTime: DateTime [0..1] + revisionNumber: String [0..1] + status: Status [0..1] ::IdentifiedObject + description: String [0..1] + mRID: String [0..1] + name: String [0..1] UsagePoints of RetailCustomer Location of premise Account ID Sub Account (SA) ID Service Agreement / Account is name depending on utility Customer name, nickname (or short name) Address and info SDG&E provides only email address and UPID correspondence csv email and UsagePoint ID (Customer Obfuscated Key) MeterID ServicePointId Pnode LoadAggregationPoint, SubloadAggregationPoint Climate zone Account open date Account close date SA Open and Close date MDM Agent Id (who does meter read) ServiceSupplierId EnergyServiceProviderId (may be same as service supplier) Demand Response Provider May need list of Ids for service providers rather than explicit?? (0..* relationship{role, href}) Related assets ???? For example pool pump and pool pump participation in a program. Related programs ???? deprecated + vip: Boolean [0..1] +CustomerAccount 1 0..* +CustomerAgreements +CustomerAgreements +CustomerAgreements 0..* +CustomerAgreements 0..* 0..* 0..* WorkLocation Customers::ServiceLocation Customers::ServiceLocation Common:: PositionPoint Common:: PositionPoint + accessMethod: String [0..1] + siteAccessProblem: String [0..1] + needsInspection: Boolean [0..1] ::Location + type: String [0..1] + mainAddress: StreetAddress [0..1] + secondaryAddress: StreetAddress [0..1] + phone1: TelephoneNumber [0..1] + phone2: TelephoneNumber [0..1] + electronicAddress: ElectronicAddress [0..1] + geoInfoReference: String [0..1] + direction: String [0..1] + status: Status [0..1] ::IdentifiedObject + description: String [0..1] + mRID: String [0..1] + name: String [0..1] +PositionPoint + xPosition: String [0..1] + yPosition: String [0..1] + zPosition: String [0..1] 0..1 +ServiceLocation +ServiceLocations 0..1 0..* +ServiceLocation 0..1 Metering:: UsagePoint Metering:: UsagePoint +UsagePoints 0..* +ServiceLocation 0..1 AssetContainer Metering::EndDevice Metering::EndDevice +EndDevices PaymentMetering::ServiceSupplier +ServiceSupplier + isVirtual: Boolean [0..1] + isPan: Boolean [0..1] + installCode: String [0..1] + amrSystem: String [0..1] ::Asset + type: String [0..1] + utcNumber: String [0..1] + serialNumber: String [0..1] + lotNumber: String [0..1] + purchasePrice: Money [0..1] + critical: Boolean [0..1] + electronicAddress: ElectronicAddress [0..1] + lifecycle: LifecycleDate [0..1] + initialCondition: String [0..1] + initialLossOfLife: PerCent [0..1] + status: Status [0..1] ::IdentifiedObject + description: String [0..1] + mRID: String [0..1] + name: String [0..1] + kind: SupplierKind [0..1] + issuerIdentificationNumber: String [0..1] 0..* 1 Metering::DemandResponseProgram Metering::DemandResponseProgram +DemandResponsePrograms + type: String [0..1] + validityInterval: DateTimeInterval [0..1] 0..* Customers:: PricingStructure Customers:: PricingStructure +PricingStructures 0..* + code: String [0..1]

Load More ...