Weekly OpenADE Meeting Notes

1. Weekly OpenADE Meeting Notes Tuesday, March 31, 2015

2. 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. – Service Request 90 – Error in GB TestPlan: FB_07,08 AccumulcationBehavior should be 4 – Service Request 91 – Error in Test Plan: FB_04 New Resources for OpenADE Exchange requested – Tariff Model Resource – Customer Information Resource • •

3. GBCMD Test Harness • Using Stunnel Proxy to isolate https from http on test harness – Three message types: • 1) DataCustodian to Mock Server – https http – Use stunnel server config (tpserver.conf) • 2) SOAPUI to DataCustodian using groovy script and httpbuilder – http https – Use stunnel client config (tpclient.conf) – host must be what is in ApplicationInformation remapped to port 8080. • 3) SOAPUI to DataCustodian via Selenium – https web browser integration – Use Selenium browser with what is in ApplicationInformation bypassing stunnel for these messages

4. Certified Link <link rel="related" href="https://cert.greenbuttonalliance.org/92348981231"/> • Added to feed (or if only entry, added to entry) • Assigned by GBA at test request submission • Until certified, may return “in progress” or some useful status • Optional request of return type for GET (returned by GBA site): 1. GET https://cert.greenbuttonalliance.org/92348981231 2. GET https://cert.greenbuttonalliance.org/92348981231?format=JSON 3. GET https://cert.greenbuttonalliance.org/92348981231, Header parameter Accept: application/json 4. Return (XML Version) – exact form tbd.

5. Chunking – When the DataCustodian needs to provide data in “chunks” • Have huge data set that DC wants to provide in “chunks” over HTTPS • Use common URI – Subscription or Bulk / id – Chunked by index and date? – Use ESPI query parameters (FB_37) to distinguish chunks <?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>../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>

6. Deferred Response when DC does not have data ready TP Request: HTTP GET https://localhost/DataCustodian/espi/1_1/Subscription/1 Content-type: application/xml DC HTTP returns 202 Request: HTTP POST https://localhost/ThirdParty/espi/1_1/Notification Content-type: application/xml Response: Request: HTTP GET https://localhost/DataCustodian/espi/1_1/Subscription/1 Content-type: application/xml HTTP returns 200 and Data • • • ThirdParty makes asynchronous request DataCustodian does not have the data ready – returns HTTP 202 Some time later (when ready no guarantees or time limit) DataCustodian sends Notification with original URL in BatchList DataCustodian provides the result •

7. Green Button Data File Summary • Can there be a “digest” of what is in a Green Button data set (i.e. feed) so that the whole data set returned by a GET or DMD can be judged for content without reviewing the contents – Different Usage Points in file may have different contents – Content may be dependent on when data is retrieved – Simple xpath statements can be used to understand the contents – Unsuitable data is likely to be asked for once not repeatedly • Consensus: Not needed

8. New XML Schema Tags • certificationNumber – Provides information about the certificate issued to the creator of the file • contentHash – Provides a checksum value of the files contents the recipient of the file may use to confirm the file has not been tampered with and all elements of the file were received – Response to OpenADE Help Desk item 86 • http://osgug.ucaiug.org/HelpDesk/Lists/servicerequests/DispForm.aspx?ID=86 &Source=http%3A%2F%2Fosgug%2Eucaiug%2Eorg%2FHelpDesk%2FLists%2Fs ervicerequests%2FGreenButton%2Easpx • Consider RFC 4287 Atom Syndication Format section 5.1 which describes Digital Signatures for Atom: https://tools.ietf.org/html/rfc4287#section-5.1

9. Certification Structure link type=“text/html” href=“https://cert.greenbuttonalliance.org/certificate/987654321987654321” />

10. Possible Options • GET https://cert.greenbuttonalliance.org/92348981231?ThisGuysScopeIs=FB_ 01040507” PGE -92348981231 – scopes=1_4_5,1_4_10,1_4_5_10 •

11. Variable return types • Query Parameter: – GET https://cert.greenbuttonalliance.org/9234898123 1?format=XML • Accept Header Parameter: – Accept: Application/XML • Atom link types – <link type=“XML” href=“https://foo.bar.com”/>

12. Certificate Solutions • Create new required resource for GB • *** Create a required feed related link • Look at other atom feed attributes to implement

13. [FB_14] OAD011 [NEG] Malformed Refresh Token Request • Verify Data Custodian rejects a malformed Refresh Token Access Token Request – Refresh_token field-value pair that was issued to another Third Party • The current CMD test harness can only simulate a single Third Party application and thus is not able to present a refresh_token request using another Third Party’s assigned refresh_token • Two application information structures would need to be registered at the Data Custodian under test to be able to support this requirement – Refresh_token field-value pair has expired • A short lived refresh_token would need to be available to perform this test requiring the Data Custodian under test to be able to modify the refresh_token expiration period • The authorization server’s token expiration test should not be based on the type of token issued, therefore the existing test in OAD016 [NEG] Invalid Access Token Request (Access Token contained in the Authorization Header has expired) makes this test redundant

14. Cell Phone API Model • How to do authorization for cell phone APP – Still need to involve App developer (DC may not accept request from any app) – API FBs – Customer and his app authentication • Get an access token – Differs in certificate management and security • Security • Privacy – Retail Customer vs Subscription

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

16. Topics • Multiple ReadingTypes in file not referenced by contents – Proposal – permit (right now excluded) • Definition of Net metering FB_07 vs. FW/REV metering FB_08

17. FB_03 • espiderived.xsd – thirdPartyUserPortalScreen vs. client_uri • Appears to duplicate same function • client_uri is optional by dynamic registration OAuth protocol • Solution – Make client_uri and thirdPartyUserPortalScreen optional in schema – Authorization.authorizedPeriod and publishedPeriod should be optional since not needed in authorizations for client admin and registration • Solution – Make both fields optional in the schema – Ensure they are present for access_token based authorizations – If present validate authorizedPeriod and publishedPeriod are valid date format – If either authorizedPeriod or publishedPeriod is present, both are required – Allow duration to be present with “0” values implying non-expiring authorizations grant_types for ApplicationInformation • Should it be set of grant_types that DC supports? • Spring requires separate client_id for client_credentials flow • Solution: – Nothing needs to change •

18. FB_03 • grant_types test assertion in FND002 re: redirect_uri – Solution: • Remove the test from FND002 and OADxxx • response_types should be “code” – Solution: • Add test to validate content of response_types is “code” • Lifetime of client_access_token – If shortlived, you need to do client_credentials each day to get a new one • This forces you to use the “secret” often which is a greater risk than client access token • What does this do the lifetime of the “Authorization”

19. CMD T&C

20. T&C Plan Now Test February Event (10/14/2014) implemented Tests defined Any needed adjustments to testees code 12/23

21. GreenButton Connect My Data Conformance Testing Requirements Review • For Review • • • • • • Not yet ready for review • FB_19 Partial data update • FB_40 Offline RetailCustomer authorization • FB_37 Query parameters FB_03 Core GB CMD FB_39 PUSH model-REST Notifications/bulk transfer FB_34 SFTP for bulk FB_35 REST for Bulk FB_13 Security FB_14 Authorization and Authentication •

22. CMD Test Development Plan • Phase I - 11/17/2014..11/21/2014 – Ron/Don Complete Spreadsheet with Test Requirements and Test Steps. – In parallel John/Marty get scheduled with consenting Data Custodians for an initial test – GET ServiceStatus which requires a target URL and a client_access_token for a preconfigured test Third Party. • Phase II - 11/19/2014..11/26/2014 – OpenADE/OpenESPI Participants review test requirements and procedures and report by exception – Don/Ron are building tests • Phase III – 12/1/2014..12/31/2014 – Don/Ron are building tests – John/Marty are running tests with consenting Data Custodians

23. 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)

24. Data Custodian Test Capabilities • Any given data custodian might fall into three possible capability categories: – The DC has the ability to clear created authorizations – The DC has multiple accounts to authorize so that when a new authorization is needed it can be created – The DC has to accept that one test failure may preclude going on to perform other tests

25. Issues • How to expire an access token so it can be tested along with refresh_token – Testee can manually or otherwise “expire” an access token • Removal of client_credential flow testing until dynamic registration – Support the API – Don’t support in minimum required • How the transition from “scope selection” which is not OAuth, to the OAuth sequence which must originate at the Third Party occurs. – Need to review Authorization document (needs corrections) and implementers need to check what they are implementing

26. DataCustodian Registration Values to Communicate with the Certification Test Harness • thirdPartyNotifyUri – https://services.greenbuttondata.org/CertificationThirdParty/es pi/1_1/Notification • thirdPartyScopeSelectionScreenURI – https://services.greenbuttondata.org/CertificationThirdParty/es pi/1_1/RetailCustomer/ScopeSelection • thirdPartyUserPortalScreenURI – https://services.greenbuttondata.org/CertificationThirdParty/es pi/1_1/RetailCustomer/home • client_name – Certification Test Harness • client_uri – https://services.greenbuttondata.org/CertificationThirdParty

27. 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: Tests almost complete 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: substantially complete FB_34 Bulk SFTP – Status: substantially complete (not on github) FB_35 Bulk REST – Status: substantially complete (not on github) • • • • • • • •

28. Authorization Resource • Currently, client_access token can retrieve the collection of authorizations for the specific third party. A concern was raised that theft of that one token would provide access to all tokens (in the Authorization resource) a serious vulnerability. Proposed solutions: 1. Keep API and schema constant but require the omission of access_token and refresh_token tags. 2. Make access to Authorization only based on the contained access_token. That is, the client_access_token can only retrieve the corresponding Authorization resource; registration_access_token can only retrieve the corresponding Authorization resource; the individual access_tokens can only retrieve the corresponding Authorization resource. Consensus solution: 3. Remove access tokens from the schema.

29. Access Tokens • Reference: http://www.greenbuttondata.org/espi/access_tokens/ • ACUDR • access_token • client_access_token • upload_access_token (used only in FB 45) • datacustodian_access_token(used only in FB_33) • registration_access_token • refresh_token ?

30. CMD Test Development Plan References • All the test development is being done on the https://github.com/energyos/OpenESPI- GreenButtonCMDTest project, and, • The test requirements and test procedures maintained in the spreadsheet at https://github.com/energyos/OpenESPI- GreenbuttonDataSDK/tree/master/GreenButtonTestingReq uirements. • You can enter issues for discussion on either project as you see appropriate. – For Test Code Issues: https://github.com/energyos/OpenESPI- GreenButtonCMDTest/issues – For Test Requirements Issues: https://github.com/energyos/OpenESPI- GreenbuttonDataSDK/issues

31. RETAIL CUSTOMER

32. Object Identification • Objects are instances of classes • Objects need to be identified uniquely because – Data in a repository needs to be identified as to where it came from – Updates to data (for example from raw to validated) need to identify that it’s the same data that has been updated – Devices from which data originates often needs to be associated with the data – Devices need to be labeled multiple ways for various purposes – e.g. in a building topology (2ndfloor floodlight), in an electrical hierarchy (branch 2 load 3)

33. IEC 61970 IdentifiedObject Master resource identifier issued by a model authority. The mRID is globally unique within an exchange context. Global uniqeness is easily achived by using a UUID for the mRID. It is strongly recommended to do this. A simple string to identify the object. class Names class Names IdentifiedObject IdentifiedObject + aliasName :String [0..1] + mRID :String [0..1] + name :String [0..1] +IdentifiedObject 1 +Names 0..* NameTypeAuthority NameTypeAuthority Name Name NameType NameType +Names +NameTypes 1 0..1 + name :String [0..1] + description :String [0..1] + name :String [0..1] +NameType + name :String [0..1] + description :String [0..1] 0..* 0..* +NameTypeAuthority The Name class provides the means to define any number of human readable names for an object. The name can be further attributed by a NameType and a NameTypeAuthority.

34. IdentifiedObject • mRID – usually a UUID that represents the object instance • name – simple string to identify the object • Name – a class that allows additional names to be used for the same object in different hierarchies. – different naming authorities may have the right to name devices for their own purposes – it is important to identify the naming authority and naming convention (type) – These must also be properties of the object to which they represent since it is the same unique object

35. ESPI Mapping of IdentifiedObject to Atom • ESPI endpoints expose resources as described by Atom, IETF RFC 4287. • Representations are identified as media type “application/atom+xml” • ESPI namespace and types (“http://naesb.org/espi”) are used for objects in <content> element • espi:mRID is implemented by atom:id – UUIDs are used, as specified in IETF RFC 4122 • espi:description is implemented by atom:title • atom:published and atom:updated are used • Associated objects use atom:link (rel=“related”) • espi:name is implemented a resource.name

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

37. Account/Agreement Topology

38. 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

39. 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]

40. 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 •

41. 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

42. 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 •

43. 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)

44. 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? • • • • •

45. FB_03 Core GB CMD • Covers “core services”, resources and access control – atom:entry, atom:feed – GET, PUT, POST, DELETE (negative only) – ApplicationInformation – Authorization (feed) – Authorization (entry) – Subscription (entry) only available through batch/subscription – ReadServiceStatus (entry) – Access token expiration testing? – Authorization expiration? – Notification move to FB_39?

46. FB_03 Core GB CMD • atom:entry / ApplicationInformation – Using required access token of R(registration_access_token) • Verify successful GET and response contents (which subset of app info is required in the response?) – If it is required by OAuth2 dynamic registration it must be present – Other fields not derived from OAuth2? – i.e. ContactInfo used in the case of a failed notification to TP • Verify negative response to PUT, POST, DELETE: 403 – forbidden – Using other access tokens(A,C) or none • Verify negative response to GET, PUT, POST, DELETE: 403 – forbidden • No token: 401 – unauthorized

47. FB_03 Core GB CMD • atom:feed / Authorization – Using required access token of C(client_access_token) • Verify successful GET and response contents (which subset of Authorization info is required in the response?) • Verify negative response to PUT, POST, DELETE: 403 – forbidden – Using other access tokens (AR) or none • Verify negative response to GET, PUT, POST, DELETE: 403 – forbidden • No token: 401 – unauthorized

48. FB_03 Core GB CMD • Authorization(C)- all fields(except error fields), some have of which have req. values • Subscriptions(A) - feed with at least 1 UsagePoint • ReadServiceStatus(C) – all fields with content of 0/1 – Using required access tokens • Verify successful GET and response contents • Verify negative response to PUT, POST, DELETE – TBD?: Using other access tokens or none • Verify negative response

49. FB_39 Push Model – REST notifications • Send Notification to TP – pre-test set up – DC needs to know TP stand-in URI (FB_33 could automate this?) – DC UT has manual “trigger method” to generate notification – ApplicationInformation – Authorization – Subscription Verify well-formed contents of the Notification Get the data (w/ correct access token) and validate the data [NEG] Test GET out of bounds and deferred response (should be moved to or is already present in other FB tests) – Authorization no longer valid (how?) – MOVE to FB_14 – Data no longer available (i.e. TP took too long for requesting the data) – SFTP error 2 ref to file that does not exist / REST GET error – Issue REST GET with wrong token (what token should the test use?) applies specifically to FB_39 to ensure notification data is secure [NEG] If TP Notify fails, verify by demonstration that failure was detected – TP is off-line • • • •

50. FB_34 SFTP for Bulk – Prerequisites • Pre configured Authorizations • Authorizations need bulk scope Notification of Bulk sent to test harness • i.e. sftp://services.greenbuttondata.org/DataCustodian/espi/1_1/resource/Batch/Bulk/{BulkID} Test harness retrieves data via SFTP Validate the data • Pass schema • Must contain 1 feed w/ 1 or more entry(s) • Verify there is a valid authorization for each entry and the scope of each authorization for each entry has BR=BulkId • Use https://services.greenbuttondata.org/DataCustodian/espi/1_1/resource/Authorization for list of authorizations to check against Is URI a pointer to a folder or a pointer to a file? SFTP GETALL – could retrieve a set of files from a folder or SFTP GET – single file – – – – – –