Here are some of the conclusions we made.

• to discover APIs Fuse Online would use the OpenAPI 2.0 document
  available on the tenant's development portal
• OpenAPI 2.0 document is publicly accessible via HTTP at /swagger/spec.json
• to maintain backward compatibility (existing /swagger/spec.json is
  served as OpenAPI version 1.2) Fuse Online will send the HTTP Accept
  header specifying the OpenAPI version requested (currently 2.0, 3.0 in
  the future)
• we identified differences in authentication methods supported
  between the products, discussed the use of security definitions from
  OpenAPI specification, validating that the authentication configured
  in API gateway integration matches the OpenAPI document was suggested

Here are some tasks that need to be done:

• work on the specification document for this
• for differences in supported authentication methods we need to
  document the supported methods
• work on the user story for Fuse Online, we need some input from Gary
  if the persona creating the API client is the same persona that knows
  the URL to the development portal, i.e. if the URL of the development
  portal is defined by a expert integrator persona and the citizen
  integrator creates the API client by choosing one of the predefined
  development portals, or does the citizen integrator start by pointing
  to the development portal

Notes we took during the meeting:
https://docs.google.com/document/d/1jWnNb8C8XWuFZK_Xnbr_Ajsmgip95Nm3rIH557PjRqw/edit?usp=sharing

Dev notes
Possible tasks on 3scale eng side:

1. Fix the endpoint that lists all the specs of a tenant, currently filtering only v1.2 specs (https://github.com/3scale/porta/blame/master/lib/developer_portal/app/controllers/developer_portal/swagger/spec_controller.rb#L13)
2. Make it possible to discover ActiveDocs from a `/.well-known/something` path
3. Override `securityDefinitions` in the spec with the actual authentication mode of the API