Define TROLIE Peering profile

[getorymckeag]

Include any API specification changes, documentation and examples for clearing ratings on tie lines between TROLIE server implementations.

[caindy]

Could you describe the use case(s) in a bit more detail? Is this part of the "peering profile" we'd discussed specifying?

[getorymckeag]

That's exactly where I was going with this. I thought it should be documented as an issue.

[caindy]

Primary functionality

Eliminate the need for a system integrator to connect to TROLIE-conformant servers. Improve application support and security scenarios for TROLIE peers.

Given a URL to a conformant peering bootstrap endpoint, e.g., trolie.example.com/peering, a server should be able to:

• securely verify the claim that the request server is authorized to act as a particular Ratings Provider
• deliver the appropriate RT ratings and forecast proposals (callback URL)
• receive the appropriate (detailed) limits snapshots (eliminates need for Conditional GET polling)

A Peering Profile conformance suite should be delivered by the TROLIE project to verify this functionality.

Secondary functionality

• early warning when the peer is unhealthy
• (optional) monitoring sets limits histograms
• (optional?) specify a monitoring set for requested snapshots

Server Identity is Precoordinated

TROLIE should make strong security recommendations (a separate conformance profile?), but authn/z may be effectively out of scope.

Handshake sketch

Any TROLIE instance can be configured with multiple peer URLs that must be associated with a Ratings Provider.

• POST /peering: defined with an OAS callback, contains the "peer-back url" which should match the precoordinated peer URL on the receiver's side (if not, returns 409 Conflict)
  • If the authenticated principal is a known Ratings Provider, returns 200 OK with a "peering profile"
  • Otherwise, 403 Forbidden
• returned "peering profile" contains
  • forecast window deadline offset and duration
  • endpoint URLs for receiving limits snapshots, e.g., your peers POST to your /limits/forecast-snapshots
  • diagnostics URL: this should contain info useful in runtime app support scenarios, like processing times, errors, etc. for the comms between the peers. suitable as a health check

[caindy]

I think we should generalize this a bit and allow TROLIE clients to GET /peering-profile. It would return the same "peering profile" info as the POST above, including a Forecast Window deadline offset.

The use case I have in mind is just testability, frankly. <deadline_offset> in the scenario below would either need to be a configuration item provided by the test to the server or something that can be retrieved at runtime. If the former, we'd be polluting the rating profile (side-loaded model) with config information, so I think the cleanest solution is to making the GET /peering-profile part of the conformance suite for forecasting and RT.

Scenario Outline: Late submissions
    Given the wall clock time at the server is <server_time>
    And the server's forecast window deadline offset is <deadline_offset>
    But the forecast submission is for <forecast_start>
    When the client submits the forecast
    Then the server responds with 409 conflict