B2B As an API Provider, I want to share our API without it appearing on the API Directory

[ikethecoder]

Overview: Numerous teams have expressed interest in being able to share their API (by share, meaning to provide a way for a client to request access and securely collect credentials to an API) with some configurable constraints like visibility on the API Directory or permission to request access (identity-based). Further work is needed to flush out this requirement with stakeholders but it relates to B2B (Business to Business) relationships within the Government (and potentially between Government and external organizations).

This Epic will capture the requirements and implement the changes on the API Services Portal to support this way of connecting API Providers with their clients in a seamless and secure way.

Some questions to consider:

• Are you looking to modernize the integration patterns with existing clients?
• Is this a new service for new clients?
• Is there a minimal set of information that would be acceptable to make public (i.e./ on the API Directory)?
• How do potential consumers (currently or you envisage) become aware of your APIs? By invitation? By partnership? By advertising somewhere?
• How do you validate the identity of consumers requesting access?
• If you have existing integrations, how do you manage the credential lifecycle (requesting, creating, revoking, expiring, auditing, etc)?

Requirements:

• As an API Provider, I only want IDIR users to request access to my API, so that I do not have an administrative overhead rejecting requests for access from non-IDIR users

[ikethecoder]

Technical Design Option No. 1

Introduce the idea of "Partners" for a namespace

Where the API Directory will have tabs for: "API Directory", "Your Products", "Partner Products". Partner Products will show all the products that you have been invited to view and request access for.

Partnerships could be established at a Namespace level - namespace 1 has a partnership with namespace 2, so namespace 1 sees Products from namespace 2.

Or partnerships could be between a namespace and an individual (same kind of screen as Namespace Access but instead of a "Grant User Access" it might be "Invite Partner" or "Share with Partner" - where you provide an Email and the Permission in the case would just be "Access.Request").

Some flushing out is needed regarding which Products are Shared - is it all? Should there be a way of specifying which Products are made available?

Do we need namespace to namespace partnership? Or can we just keep it to individuals?

If the partner is another namespace, then there should be a "My Access" kind of screen within the context of a Namespace, so that Namespace administrators can manage credentials that are applicable to their namespace. The reality is that a Product Environment is equivalent to an Application.

[JohnathanBrammall]

Can the same pattern be used for Organization where a namespace partners with an organization so that authenticated members in that organization (namespaces assigned to that organization and/or the hierarchical structure) are able to view and request access?

[ikethecoder]

Technical Design Option 2

Add an "Integrations" to the Namespace page, where a user will be able to (1) establish relationship with another Organization Namespace, and (2) request access

On the Integrations page, it will have similar information as the My Access page, except that it will be grouped by Organization, and instead of "Application", it will be a "Product/Environment". The "Establish Relationship" will prompt the user to enter in the partner Namespace, and then the Organization will show "Established" when someone from the other Namespace agrees. Once established, a user is able to browse the APIs that are available for that Organization, and can request access ("+ Add Integration") using a similar Request Access dialog.

The Product Environment detail could be enhanced when the "Enable Environment" is checked, an additional checkbox could display with "Established Relationships Only" (as opposed to "Public").

[sienna-blumstengel-bcgov]

Made a parallel epic for this in JIRA: https://dpdd.atlassian.net/browse/APS-1472