Add examples showing how a multi organization setup would work.

[MariusStorhaug]

The use-case:

• A large enterprises scale on organizations (in Azure DevOps these units of scale are more correctly called 'Projects').
• Inner-source communities for shared libraries and reusable components typically follow the guidelines GitHub share for open-source code, but remove the benefit of anonymous access to public repos. There is no such construct in GHEC. Repos are internal or private. Clue is multi organization setup.
• A team has code that takes dependency on resources from one or more inner-source community that has created language based libraries to make teams more efficient internally.

Question:
How can we use OCTO-STS to grant workflow access to other organizations?

[cpanato]

Question:
How can we use OCTO-STS to grant workflow access to other organizations?

Using GitHub actions, you cannot do that; you might want to use some serverless function or another approach, but using GitHub actions, that is not possible; the tokens generated only belong to the ORG that the app was installed

[mattmoor]

Octo STS can federate for a token in another org, you just need the right federation rules.

Because of how things work, each org will require a different federation since GitHub apps can’t auth to multiple orgs simultaneously

[MariusStorhaug]

@mattmoor @cpanato : You can, its just requires that you have a GitHub app that is installed on all orgs, and have the client id and pem in the org + some action similar to the octo-sts that iterates over all app installations and stores git config as either an insteadOf or credential.*.helper config.