College Apps Essay Results Fall 2015
In Fall 2015, results of college applications essay for DE102 periods 1 and 4 were shared. The breakdown of grades, student feedback, and areas for improvement were discussed, along with examples of thesis statements and guidance for future essay preparation.
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.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
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.
E N D
Presentation Transcript
Weekly OpenADE Meeting Notes Tuesday, October 28, 2014
OpenADE Task Force Topics Green Button Connect My Data Testing and Certification (target fall 2014) Complete function block descriptions Complete test case requirements Amend DMD test requirements if gaps are discovered in dry run or other process Issues Raised and Implementation Questions How to use BR=bulkID with application to account and account groupings, as well as, large ThirdParty collections of Authorizations. Service Request 83 including Function Block for optional customer info (service point address, etc.) Service Request 84 having scope selection screen on Data Custodian Site vs 3rdParty site (need to write up description) Service Request 85 Duplicating TOU and CPP from ReadingType to IntervalReading as in SEP 2.0 Service Request 86 Desire to add digital signature to Green Button data to protect against tamper. New Resources for OpenADE Exchange requested Tariff Model Resource Customer Information Resource
Topics RetailCustomer schema GBCMD Testing and Certification Third Party Portal penny test and how it relates to GBCMD test February Event The Birth of the Green Button Ecosystem Irregular interval data Scope Selection in Oauth namespacing? How to constrain the meaning of Scope parameter for Oauth when there may be other Oauth based services coexisting on the AuthorizationServer UsagePoint relationships aggregation of submeters, etc Query Parameters that don t match up exactly with data Interpretation of Quality Flags for UsageSummary, ReadingType, and IntervalReading ReadingType attributes? Quality of Reading value 19 service request added Use of ElectricPowerUsageSummary -> UsageSummary -> Supporting billing directly and with multiple utilities. What is best practice for ElectricPowerUsageSummary, ElectricPowerQualitySummary Service request #85 Duplicating TOU and CPP from ReadingType to IntervalReading as in SEP 2.0 Correlation IDs for REST messages
Separation of PII containing Resource RetailCustomer from Subscription* PII Containing information Anononymous EUI Subscription RetailCustomer 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
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]
RetailCustomer API GET .../resource/Batch/RetailCustomer/{id} GET .../resource/RetailCustomer/{id} GET .../resource/RetailCustomer/{id}/CustomerAccount/{id}/CustomerAgreement/{id} GET .../resource/CustomerAgreement/{id} GET .../resource/Batch/BulkRetailCustomerInfo/{id} Authorization Scope string addition? RCInfo=AC where A=Address included , C=AccountInfo included RCBulkId=123 for access to account info in bulk Access tokens to access? Individual with access_token, bulk with client_access_token FB Has RetailCustomer Just one FB_4X with RCInfo Has Additional Detail indicated by content of RCInfo
[FB_39] PUSH model Send Notification to TP UUT has manual trigger method to generate notification Fetch by SFTP if resource URI has sftp:// Fetch by GET if URI is https:// Get the data and Validate the data Bulk? data once per day; corrections once per day; Resource? authorizations on as needed; Issue: All didn t do SFTP get support yet [NEG] Test GET out of bounds and deferred response Authorization no longer valid Data outside contract period bounds Wrong token Verify applicationinformation has valid contact info [NEG] If TP Notify fails, verify by demonstration that failure was detected
FB 13: Security Testing Cyber Security and Privacy Test Requirements Based on Authorization.docx section 2.7 From SGIP SGCC Committee review of REQ.21 Reviewed with NIST Cyber Security staff NAESB REQ.21 section Initial set of test requirements on next slide
FB 13: Security Testing Initial Set of Test Requirements [TR_TC001] Test software shall issue a service request over an SSL session and shall verify that the response HTTP header contains the following fields and information fields TBD [TR_TC002] Verify that REST request headers include fields TBD [TR_TC003] Verify that the Data Custodian implements TLS 1.2. [TR_TC004] Verify that when communicating with a Retail Customer the Data Custodian negotiates the highest level of TLS mutually supported. [TR_TC005] Verify that when communicating with a Retail Customer the Data Custodian rejects TLS_RSA_WITH_NULL_SHA cipher suites. [TR_TC006] Verify that when communicating with a Retail Customer at a minimum the Data Custodian accepts the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. [TR_TC007] Verify that when communicating with a Third Party the Data Custodian negotiates the highest level of TLS mutually supported. [TR_TC008] Verify that the Data Custodian maintains an unexpired unrevoked RSA certificate with a public key length of at least 2048 bits. [TR_TC009] Test software or manual inspection shall verify that the Data Custodian RSA certificate was issued by a Certificate Authority (CA) that has been successfully audited according to the criteria of ETSI or WebTrust. [TR_TC010] Test software or manual inspection shall verify that Tokens and IDs communicated by the Data Custodian are opaque and if based on actual Customer information that they are randomized using a secure method to protect privacy. [TR_TC011] Test software or manual inspection shall verify that Tokens and IDs communicated by the Data Custodian consist of at least 48 bits and can be the random number part of an RFC2422 UUID. [TR_TC012] Manual inspection of supporting documentation shall confirm that the Data Custodian implementation utilizes software libraries which are FIPS 140-2 level 1 or higher and listed on the CMVP website. [TR_TC013] Verify that the Third Party implements TLS 1.1 or higher. [TR_TC014] Verify that when communicating with a Retail Customer the Third Party negotiates the highest level of TLS mutually supported. [TR_TC015] Verify that when communicating with a Data Custodian the Third Party negotiates the highest level of TLS mutually supported. [TR_TC016] Verify that the Third Party maintains an unexpired unrevoked RSA certificate with a public key length of at least 2048 bits. [TR_TC017] Test software or manual inspection shall verify that the Third Party RSA certificate was issued by a Certificate Authority (CA) that has been successfully audited according to the criteria of ETSI or WebTrust. [TR_TC018] Test software or manual inspection shall verify that Tokens and IDs communicated by the Third Party are opaque and if based on actual Customer information that they are randomized using a secure method to protect privacy. [TR_TC019] Test software or manual inspection shall verify that Tokens and IDs communicated by the Third Party consist of at least 48 bits and can be the random number part of an RFC2422 UUID. [TR_TC020] Manual inspection of supporting documentation shall confirm that the Third Party implementation utilizes software libraries which are FIPS 140-2 level 1 or higher and listed on the CMVP website.
FB_14: Authorization and Authentication (OAuth)
FB_19: Partial update of data Is this requirement for upload role and not core data custodian?
[FB_37] Query Parameters Support published_min, published_max
GBCMD Testing and Certification Status Test Project and Harness Need to add target UUT configuration and refactor tests FB_3 Core Green Button Connect My Data Status: Initial set of tests complete; need more negative cases and results analysis FB_13 Security and Privacy Status: Initial set of test complete; need to adjust to test harness and needs some small enhancements FB_14 Authorization and Authentication Status: Repertoire of test cases initially identified by Don Coffin and they need to be reviewed and implemented implementation begun FB_19 Partial Update Data Status: not started FB_37 Query Parameters Status: not started FB_39 PUSH Model Status: not started
GBCMD Test Plan Set UUT into Test Harness Harness acts as a TP Need test third party account At least three Test Accounts Two authorized for this third party One known and authorized for any other third party Create / Exchange ApplicationInformation for Test TP Create / Exchange TP client_access_token TP registration_access_token Two Subscription access_token (may included OAuth authorization process) Third subscription access_token (not owned by TP and used in negative tests)
T&C Plan Now Test February Event (10/14/2014) implemented Tests defined Any needed adjustments to testees code
February Event Preliminary Planning Celebrate: Birth of the Green Button Ecosystem Testing and Certification Complete for DMD/CMD UCAIug ITCA fully established Initial Data Custodians successfully certified for DMD and CMD Shower Successful T&C Adopters with Fame and Congratulations Venue and participation TBD in coming weeks
Best Practice Reading Quality Flags ReadingType.defaultQuality contains the default quality that applies to all corresponding IntervalReading data. IntervalReading.ReadingQuality.quality allows specific Intervals to override the default in ReadingType UsageSummary.qualityOfReading if present overrides default in ReadingType for those IntervalBlocks within the scope of the UsageSummary.billingPeriod If IntervalReading data are modified, DataCustodian should notify of this change so ThirdParty can retrieve the changes. If UsageSummary.qualityOfReading overrides the ReadingType or IntervalReadings, the IntervalReading qualities would change and a subsequent retrieval (not required) of the IntervalBlocks would come with the corresponding quality flag. The qualityOfReading flag for Usage Summary will indicate latest overriding quality of previously provided interval values corresponding to BillingPeriod dates The Default Quality (from ReadingTypeRef) for OverallConsumptionLastPeriod will indicate quality of total billed usage
Requests that are not inside authorization period (i) 3P Requested Period (completely outside) 9/1/2013 12/31/2013 Date of request April 5 1/1/2014 12/31/2014 (ii) 3P Requested Period (partially outside) Consensus: i agree on 403 ii agree on 403 11/1/2013 3/31/2014 Expected Result? (i) (ii) Options: 1.Return 403 unauthorized request for both complete and partial scenarios 2.Return 400 bad request for both cases (since the request params are bad but the tokens are valid) 3.Return 200 with a.Feed for the partially authorized period (per example: 1/1/14 3/31/14) b.Empty feed for the period which is completely outside the authorized period (per example: 11/1/2013 12/31/2013)
FB3 - Core REST Services [R] GET resource/ApplicationInformation/{ApplicationInformationID} [POS] Accept of valid request [NEG] Reject by invalid ID [NEG] Reject by invalid access-token [POS] Results valid to schema and include required fields for OAuth and TP/DC interaction [C] GET resource/Authorization [C] GET resource/Authorization/{AuthorizationID} [A] GET resource/Batch/Subscription/{SubscriptionID} [C] GET resource/ReadServiceStatus POST: How to test for TP Notification Trigger Uses notification URI from ApplicationInformation Expected content at least one URI that can be GET d?
Older or other slides Will build deck with new content over time.
ReadingType Attributes PG&E notices that their MDM uses various ReadingType attribute values that are not the same as those in the DMD test suite. Question should meter data reflect the diversity of the meter system or the meaning of data conveyed to the ThirdParty Folks will look at their data and thinking further.
Interpretation of Quality Flags for UsageSummary, ReadingType, and IntervalReading ReadingType.defaultQuality contains the default quality that applies to all corresponding IntervalReading data. IntervalReading.ReadingQuality.quality allows specific Intervals to override the default in ReadingType If IntervalReading data or quality tags are modified, DataCustodian should notify of this change so ThirdParty can retrieve the changes. UsageSummary.qualityOfReading if present indicates that those IntervalBlocks within the scope of the UsageSummary.billingPeriod may have changed quality as well. Third Party may want to retrieve data again to see the revisions if any. The DC may indicate to the TP that IntervalBlock data has changed by sending a notification for the IntervalBlocks that changed.
Testing and Certification Issues Test Third Party role for testing DataCustodian Test accounts (how many ; real-or-not ; how much history?) Test Set up Application Information How to put DC in reproducible state reset? Minimum FBs to test FB_3, 13, 14, 19,37,39 Alternative Test Environment that is same as the Live environment Same Certs etc Does it need to be real data?
ElectricPowerUsageSummary Make general UsageSummary and deprecate ElectricPower one Let query determine period not current/last How to rename fields to remove current/last ambiguity for past requests Determine what required fields might be and some possible new FB to support ecosystem interoperability Single Demand fields too limiting for modern tariffs.
UsageSummary Recommendataions Create new UsageSummary (which is NAESB REQ.18 name) Add new tags recommended by PG&E Retain all existing tags and make UsageSummary and ElectricPowerUsageSummary identical but mark old one deprecated for backwards compatibility new implementations will have to accept either Resource on input Revise descriptions of existing tags to make clear what goes with billing period etc. Provide documentation on how to interpret query parameters for GET UsageSummary
UsageSummary Use Cases I ask for summary today (with day later publishing) I ask for 3 months last year (query parameters?) Billing period is non-calendar John: I ask for an arbitrary period roll-up of consumption GET UsageSummary min=1/15/2014&max=2/28/2014&rollup=True In PGE concept you get 2 UsageSummarys one for billing period January and one for billing period February In John concept you get 1 UsageSummary with totals for 1/15..2/28
Documentation Issues Do in GreenButtonAuthorization.docx section 2.4 Use Cases for Authorization Termination (revocation) -- DC-oriented control of termination process due regulatory requirements in Ca. Do in section 2.8 Behavior of GET UsageSummary with query parameters
Service Request 83 including Function Block for optional customer info (service point address, etc.) Requirements Implementation Resource Definition REST service to exchange resource(s) GET only Function Block(s) Wholesale vs Retail Optionality vs Required Possible Scope spec 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 from Lynn will provide more information SDG&E provides only email address and UPID correspondence csv email and UsagePoint ID (Customer Obfuscated Key) Current ESPI resources will never return PII GET Subscription does not contain PII Single Authorization covers entire Subscription and Authorization Scope 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 ???? Probably multiple resources are good idea
For May 20 Topics Use Case for verified for billing Added <xs:annotation> <xs:appinfo>revenue-quality</xs:appinfo> <xs:documentation>data that is valid for billing purposes</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="19"> ServiceStatus return data Simple status or, outstanding batchlists Consensus: Don t really need this extension because the DC can determine if it wants to send a notification of what hasn t been retrieved at its discretion. Revised Authorization document Use Case for Small ThirdParty / Mega ThirdParty maybe another day in future
Service Status Consensus: Don t really need this extension because the DC can determine if it wants to send a notification of what hasn t been retrieved at its discretion. As is in standard <?xml version="1.0" encoding="UTF-8"?> <ServiceStatus xmlns="http://naesb.org/espi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://naesb.org/espi espiDerived.xsd"> <currentStatus>1</currentStatus> </ServiceStatus> Enhanced to add current outstanding batchlist <?xml version="1.0" encoding="UTF-8"?> <ServiceStatus xmlns="http://naesb.org/espi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://naesb.org/espi espiDerived.xsd"> <extension>text</extension> <currentStatus>65535</currentStatus> <batchList> <resources>../espi/1_1/resource/Batch/Bulk/1?start-index=1&max-results=1000&published-max=2012-04-02T04:00:00Z& published-min=2012-04-02T04:00:00Z</resources> <resources>../espi/1_1/resource/Batch/Bulk/1?start-index=1&max-results=1000&published-max=2012-04-02T04:00:00Z& published-min=2012-04-02T04:00:00Z</resources> </batchList> </ServiceStatus>
Authorization What happens when authorization changes UsagePoints or period When Authorization changes, place authorizationUri in notification to ThirdParty which can then re-establish its state
What can you negotiate with Scope? FBTerms data content, CMD services ValueTerms default durations and blocking, history length, subscription frequency (i.e. daily data cycle) ResourceTerms specific resources available by api, bulkID assignments, bulkaccount Other?
Scope Negotiation Oversimplified sequence diagram of Use Case #2 showing essence of scope negotiation TP DC RC Logon Logon HTTP Redirect with Scope={scope1} {scope2} Authorization request Scope={scope2} Authorization response Scope={scope2} access-token resourceUri authorizationUri referenceId
Scope issues Limit Scope to access-token and minimal exchange requirements Add list of UPs in a subsequent GET request Could include UPs, optional location, additional data We would define new resource that has this data Are there options? FB_XX Minimum data UsagePoint FB_XY Optional data location Should it be a different namespace and XSD? We need to make sure they are mutually exclusive the usage and the PII containing data Namespace and separate schema minimize the opportunity for comingling of data Single authorization with multiple UPs with different scopes Don suggested that the scope is a union of capabilities. You need to get the data to see details Jerry suggests scope be provided with UP?
CSV from GB Data GBData.XML CSV File that opens in Excel XSLT Transform GreenButtonDa taStyleSheetCS V.xslt ======================================== Usage Information For: Front Electric Meter ======================================== Meter Reading Information Type of readings: Electricity ======================================== Detailed Usage ======================================== Start date: 2012-03-01 00:00 for14 days ======================================== Interval Blockdata for period starting: ======================================== Energy consumption time period 2012-03-01 00:00 to 2012-03-01 00:15 2012-03-01 00:15 to 2012-03-01 00:30 2012-03-01 00:30 to 2012-03-01 00:45 2012-03-01 00:45 to 2012-03-01 01:00 2012-03-01 01:00 to 2012-03-01 01:15 2012-03-01 01:15 to 2012-03-01 01:30 2012-03-01 01:30 to 2012-03-01 01:45 Fifteen Minute Electricity Consumption Real energy in kilowatt-hours Two-Phase Residential Service 2012-03-01 00:00 for 1 day Usage(Real energy in kilowatt-hours) Cost(US Dollar) Events occurred 0.282 0.323 0.294 0.331 0.321 0.316 0.299 0.01 0.01 0.01 0.01 0.01 0.01 0.01 8 7
Notification TP DC HTTP POST Content-type: application/atom+xml <?xml version="1.0" encoding="UTF-8"?> <BatchList xmlns="http://naesb.org/espi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://naesb.org/espi espiDerived.xsd"> <resources>https://services.greenbuttondata.org/DataCustodian/espi/1_1/resource/Subscription/ 1</resources> </BatchList>
A Couple of Use Cases Use Case 1: How to do Gas and Electric in one Authorization An Authorization Two UsagePoints One Gas One Electric Different Scope Use Case 2: CISR based Authorization Customer logs in has id for utility website Each login has multiple electricity accounts Each account can be multiple usage points Customer login id becomes obfuscated {referenceId} which can be used in REST Uris of the form: /espi/1_1/resource/RetailCustomer/{referenceId}/** Authorization enables a subcriptionID and authorizationID which is (internally) correlated to the customer and the subselection of usagepoints
Discussion on Authorization Structure Authorization enables the following URLs: <resourceURI>http://localhost:8080/DataCustodian/espi/1_1/resource/Batch/Subscription/1</resourceURI> <authorizationURI>http://localhost:8080/DataCustodian/espi/1_1/resource/Authorization/1</authorizationURI> /espi/1_1/resource/RetailCustomer/<referenceID>/UsagePoint/... (SA == UsagePoint, CISR == subscription == authorization) with Access-token GET /espi/1_1/resource/RetailCustomer/<referenceID>/UsagePoint <feed> <entry> <id>urn:uuid:40BE6242-F7E6-4B51-828E-59B5FC0C35F0</id> <link rel="self" href="https://localhost:8080/DataCustodian/espi/1_1/resource/RetailCustomer/9B6C7065/UsagePoint/5446AF3F"/> <link rel="up" href="https://localhost:8080/DataCustodian/espi/1_1/resource/RetailCustomer/9B6C7065/UsagePoint"/> <link rel="related" href="https://localhost:8080/DataCustodian/espi/1_1/resource/RetailCustomer/9B6C7065/UsagePoint/5446AF3F/MeterReading"/> <link rel="related" href="https://localhost:8080/DataCustodian/espi/1_1/resource/RetailCustomer/9B6C7065/UsagePoint/5446AF3F/ElectricPowerUsageSummary"/> <link rel="related" href="https://localhost:8080/DataCustodian/espi/1_1/resource/LocalTimeParameters/01"/> <title>a galaxy far, far away</title> <content> <UsagePoint xmlns="http://naesb.org/espi"> <ServiceCategory> <kind>0</kind> </ServiceCategory> </UsagePoint> </content> <published>2012-05-03T04:00:00Z</published> <updated>2012-05-03T04:00:00Z</updated> </entry> ... </feed>
Customer Information Resource Requirements UsagePoints of RetailCustomer Location of premise Account ID Sub Account (SA) ID -- Service Agreement / Account is name depending on utility Customer name SDG&E provides only email address and UPID correspondence csv email and UsagePoint ID (Customer Obfuscated Key) Current ESPI resources will never return PII GET Subscription does not contain PII Single Authorization covers entire Subscription and Authorization Scope Implementation Resource Definition REST service to exchange resource(s) Function Block Possible Scope spec
class NAESB PAP10 EUI Diagram NAESB REQ.18 Extended Customer Information class NAESB PAP10 EUI Diagram ServiceSupplier ServiceSupplier + kind :SupplierKind [0..1] + name :String [0..1] +CustomerAuthorisations IdentifiedObject CustomerAuthorisation +CustomerAgreements 0..* +ServiceSuppliers 1..* + authorizationServer :anyURI [0..1] + authorizedPeriod :DateTimeInterval [0..1] + name :String [0..1] + validityInterval :DateTimeInterval [0..1] + accessToken :String32 [0..1] + publishedPeriod :DateTimeInterval [0..1] + resource :anyURI [0..1] + status :UInt8 [0..1] 0..* CustomerAgreement CustomerAgreement + name :String [0..1] This data is already part of the PAP10 parent model to ESPI REQ.18 0..1 +CustomerAgreement +ServiceDeliveryPoints 0..* +Customers 0..* +ServiceDeliveryPoints 0..* IdentifiedObject Customer EndDeviceAsset EndDeviceAsset ServiceDeliveryPoint ServiceDeliveryPoint TariffProfile TariffProfile Customer + name :String [0..1] + name :String [0..1] + name :String [0..1] + name :String [0..1] 0..1 0..* 0..* +TariffProfile 0..1 +EndDeviceAssets +ServiceDeliveryPoints +Customer class CustomersOverview class CustomersOverview ServiceCategory ServiceCategory + kind :ServiceKind [0..1] WorkLocation 0..1 +ServiceCategory ServiceLocation ServiceLocation PositionPoint 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 + aliasName :String [0..1] + description :String [0..1] + mRID :String [0..1] + name :String [0..1] +UsagePoints +UsagePoint + xPosition :String [0..1] + yPosition :String [0..1] + zPosition :String [0..1] +UsagePoint 0..1 0..* +UsagePoints 0..* +PositionPoint IdentifiedObject UsagePoint 0..1 0..* 0..1 + name :String [0..1] + description :String [0..1] + status :Integer + roleFlags :RoleFlags +UsagePoint This data is part of CIM and associated with CustomerAgreement ServiceLocation may be equal to ServiceDeliveryPoint which is no longer in CIM
Common Information Model (CIM) Customer Overview IEC 61968 and IEC 61970 class CustomersOverview class CustomersOverview Document WorkLocation +CustomerAccounts CustomerAccount CustomerAccount ServiceLocation ServiceLocation +CustomerAccount +ServiceLocations 0..* + billingCycle :String [0..1] + budgetBill :String [0..1] + accessMethod :String [0..1] + siteAccessProblem :String [0..1] + needsInspection :Boolean [0..1] 1 0..* +Customer 1 +CustomerAgreements +CustomerAgreements 0..* OrganisationRole Customer 0..* Customer Agreement +CustomerAgreements + 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] +CustomerAgreements CustomerAgreement CustomerAgreement +Customer 0..* 0..* + loadMgmt :String [0..1] 1 +ServiceCategory 0..1 +CustomerAgreements 0..* IdentifiedObject ServiceCategory ServiceCategory +PricingStructures 0..* Document + kind :ServiceKind [0..1] +ServiceCategory PricingStructure PricingStructure 1 Document + code :String [0..1] + revenueKind :RevenueKind [0..1] + taxExemption :Boolean [0..1] + dailyEstimatedUsage :Integer [0..1] + dailyCeilingUsage :Integer [0..1] + dailyFloorUsage :Integer [0..1] +Tariffs +PricingStructures Tariff Tariff +PricingStructures + startDate :Date [0..1] + endDate :Date [0..1] 0..* 0..* 0..*
UsagePoint (from espiderived.xsd) Obfuscated tariff ID Obfuscated customerAgmtID
Possible Arrangement of Data pulling the string RetailCustomer UsagePoint ServiceLocation Customer Agreement Normal ESPI Resources EndDeviceAsset ServiceSupplier PostionPoint Key TariffProfile Account Resource Authorization Existing Resource ERP Resource
Possible Arrangement of Data pulling the string RetailCustomer UsagePoint EndDeviceAsset ServiceLocation Customer Agreement Key New Resource PostionPoint Authorization Existing Resource TariffProfile Non-resource included ServiceSupplier
FB3 - Core REST Services [TR_CR003] Verify ReadServiceStatus returns active status
FB31 - Core REST Services [TR_CR001] Verify the Authorization can be retrieved using the authorizationUri (from the authorization process in FB-14 or FB-40) [TR_CR002] Verify the Authorization resource does not contain PII by inspection [TR_CR003] Verify ReadServiceStatus returns active status [TR_CR004] Verify Batch/Subscription/{subscriptionId} returns a valid Atom feed with all UsagePoints and related data including all interval data [TR_CR005] Verify structured URIs are of the form {DataCustodianResourceEndpoint}[/{keyterm}/{id}]* based on the structure of Green Button APIs [TR_CR006] Verify /RetailCustomer/{retailCustomerID}/UsagePoint Returns list of UsagePoints only under the Authorization [TR_CR007] Verify Batch/RetailCustomer/{RetailCustomerId}/UsagePoint/{UsagePointId} Returns all data under and including a single UsagePoint [TR_CR008] Verify that resources returned by the resourceUri are valid to the schema, proper linking, and verify that the data meets the test requirements based on PICS for content and consistency
FB 13: Security Testing Cyber Security and Privacy Test Requirements Based on Authorization.docx section 2.7 From SGIP SGCC Committee review of REQ.21 Reviewed with NIST Cyber Security staff NAESB REQ.21 section Initial set of test requirements on next slide
Initial Set of Test Requirements [TR_TC001] Test software shall issue a service request over an SSL session and shall verify that the response HTTP header contains the following fields and information fields TBD [TR_TC002] Verify that REST request headers include fields TBD [TR_TC003] Verify that the Data Custodian implements TLS 1.2. [TR_TC004] Verify that when communicating with a Retail Customer the Data Custodian negotiates the highest level of TLS mutually supported. [TR_TC005] Verify that when communicating with a Retail Customer the Data Custodian rejects TLS_RSA_WITH_NULL_SHA cipher suites. [TR_TC006] Verify that when communicating with a Retail Customer at a minimum the Data Custodian accepts the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. [TR_TC007] Verify that when communicating with a Third Party the Data Custodian negotiates the highest level of TLS mutually supported. [TR_TC008] Verify that the Data Custodian maintains an unexpired unrevoked RSA certificate with a public key length of at least 2048 bits. [TR_TC009] Test software or manual inspection shall verify that the Data Custodian RSA certificate was issued by a Certificate Authority (CA) that has been successfully audited according to the criteria of ETSI or WebTrust. [TR_TC010] Test software or manual inspection shall verify that Tokens and IDs communicated by the Data Custodian are opaque and if based on actual Customer information that they are randomized using a secure method to protect privacy. [TR_TC011] Test software or manual inspection shall verify that Tokens and IDs communicated by the Data Custodian consist of at least 48 bits and can be the random number part of an RFC2422 UUID. [TR_TC012] Manual inspection of supporting documentation shall confirm that the Data Custodian implementation utilizes software libraries which are FIPS 140-2 level 1 or higher and listed on the CMVP website. [TR_TC013] Verify that the Third Party implements TLS 1.1 or higher. [TR_TC014] Verify that when communicating with a Retail Customer the Third Party negotiates the highest level of TLS mutually supported. [TR_TC015] Verify that when communicating with a Data Custodian the Third Party negotiates the highest level of TLS mutually supported. [TR_TC016] Verify that the Third Party maintains an unexpired unrevoked RSA certificate with a public key length of at least 2048 bits. [TR_TC017] Test software or manual inspection shall verify that the Third Party RSA certificate was issued by a Certificate Authority (CA) that has been successfully audited according to the criteria of ETSI or WebTrust. [TR_TC018] Test software or manual inspection shall verify that Tokens and IDs communicated by the Third Party are opaque and if based on actual Customer information that they are randomized using a secure method to protect privacy. [TR_TC019] Test software or manual inspection shall verify that Tokens and IDs communicated by the Third Party consist of at least 48 bits and can be the random number part of an RFC2422 UUID. [TR_TC020] Manual inspection of supporting documentation shall confirm that the Third Party implementation utilizes software libraries which are FIPS 140-2 level 1 or higher and listed on the CMVP website.
[FB_14] Authorization and Authentication (Oauth 2.0) Verifying response to invalid authorization request (invalid access-token for resource) Verify rejection of request missing access-token Missing header parameters Invalidation of access-token at end of authorization period
