Support for Browser-Based Auth from CLIs

[ThisIsMissEm]

Over on the RFCs repository, I've had open the discussion to implement Browser-Based authentication. Unfortunately, I've not been able to take this further than a discussion at the moment, as I can't exactly spend unpaid time on open-source whilst freelancing and starting a company.

However, I would really like to push this forwards soon, as it's a constant pain source and I've lost countless hours helping people authenticate with registries other than npm's official registry (Github Packages, Verdaccio). The sooner we can get this feature past RFC (it's already been discussed a lot), built, and shipped, the sooner people will be able to use private packages with a simple, easy to use workflow.

I would love to see this feature brought on to the npm roadmap, even though it's still just a discussion over on the RFCs repo. The difference in end-user experience will be extraordinary when working on any project that required private packages.

For instance, common problems I've encountered with using:

• GitHub Packages
  • mismatched public email and account email
  • missing SSO permission on private access token
  • missing permissions on private access token
  • users not knowing how to create private access tokens
  • missing organisation membership or packages permission (this one was weird and unclear to debug and then suddenly worked)
• Verdaccio (with SSO via GitLab):
  • JWT token was several megabytes causing verdaccio to break due to max-header size in nginx
  • difference between access token on GitLab and login token with Verdaccio

Browser-Based Authentication means all of these issues can be address in the respective frontends for the various repositories, resulting in the user either cancelling the authentication flow (not logging in) or logging in and getting valid crendential so the next npm install or yarn install works flawlessly*.

[MylesBorins]

Thanks for opening @ThisIsMissEm!

At a high level are you imagining an experience that is similar to what is done in the recently released GitHub CLI?

[ThisIsMissEm]

We may need to implement something in how the registry chooses what URL to connect to for device-code flow, I note that GitHub Packages uses /login/device/code and npm's own form of "device code grant flow" (known as WebAuth in the CLI code) uses /-/v1/login

[dantman]

I know I'm overcomplicating this a bit, but OIDC has a method of discovering OAuth 2 endpoints that could be used to do discovery based on the repository url.

I could also swear there was a better native application OAuth flow, but all I can find is examples that start a local webserver and use the auth code with PKCE flow.

[ThisIsMissEm]

@dantman are you talking about the GET /.well-known/openid-configuration endpoint? I could imagine that being used here, I was originally thinking a /.well-known/registry-info endpoint to fetch back the mechanism of how to authenticate, and that info would be cached per registry.

[ThisIsMissEm]

@dantman though the goal is to try and unify around a single url, e.g., /-/v2/login or something and say "this is an endpoint that is mandatory for registries to implement", and that endpoint would then give the URLs for the browser to be opened to and the client to poll. I guess if you wanted to have that URL be dynamic on a per-registry basis, then you could do a /.well-known request for the registry first, before doing the call.

I guess it depends on how much configurability you want here, whether clients should discover everything about the registry based on a URL mapping (action => endpoint), or whether you want to standardise the registry API.

[dantman]

Yeah, that's the endpoint. I was thinking about it because it's a standard related to what we're discussing and there are already client libraries that implement it.

There's also the option of using other parts of OIDC. e.g. OIDC's /userinfo could be used as part of npm whoami.

[ethomson]

I haven't had an opportunity to read the RFC issue in detail yet. I'll try to grab some time early next week. But naively, this feels very much like the same problem that git has - you have a tool that has no special knowledge of the auth flows of the providers (git), and you have providers that have a system to create PATs (GitHub, GitLab, Bitbucket, Azure DevOps, etc). This feels very similar to npm/yarn and the npm registry, GitHub Packages, Artifactory, etc.

The thing that bridges that gap is the git-credential mechanism, which is a command-line based API for getting / storing credentials. And then there's tools like Git Credential Manager that handle the authentication flow and obtaining a PAT from those services.

I guess my question is whether doing all this work in the CLI itself is necessary or we can just build a communications channel by which we let other people plug in whatever authentication provider they want. If so, can we reuse the existing git credential manager protocol.

In many ways, it's easier to add support for an existing auth flow to a standalone open source tool than to convince all the registries to support a particular endpoint.

[ethomson]

If we'd like to lift authentication up out of the CLIs to another layer, then that's a separate more complicated conversation, than just implementing a standardised way to do browser-based logins, which is what this aims to focus on.

I don't think that it is a separate conversation. If the goal is to improve the CLI login flow, then oauth device flow is one possible solution to that problem. And it's rather complicated itself, because as you noted in the other issue, there's engineering work required in:

npm Registry (both enterprise and public)
npm CLI
yarn CLI
verdaccio & other private registry implementations.

For a greenfield client/server application, I really like the webauth device flow proposal. But (IIUC) this proposal suggests changes to every npm client and registry. And as someone who manages three registries - and works closely with the people who manage two others - it would be hard to land a new auth flow in all three of those -- and those are the easy ones where we control the auth stack end-to-end. GitHub Packages would need the coordination of several teams to land this functionality to add a new auth flow.

(Interestingly, Azure does do a similar pattern here for their CLI. So Azure Artifacts may be the closest registry to supporting this functionality.)

I suggested the credential manager approach because it abstracts away a number of messy details like how to get a token from a provider, how to store a token, and then how to retrieve that token again later. It can merrily talk to npm's API or GitHub's REST API or verdaccio's. Now, this doesn't solve the API proliferation problem - yes, it would be nice to have a standard - but (with the possible exception of verdaccio) these APIs exist today to be used. We're not asking the registries to add another (duplicate) API in the hopes that they are.

Second, it can address the storage issues. Because:

This also doesn't necessarily change how we retrieve authentication credentials or tokens at a later date, but rather how do you authenticate a user at a given point in time, shifting from requesting credentials via the CLI, to a purely browser based approach (remember, for machine authentication you're not going to be calling login/adduser)

This feels like a missed opportunity, IMO. Instead of storing an access token in ~/.npmrc, we could use the system's facility to securely store them (Keychain, Windows Credential Manager, etc).

The credential manager protocol that git uses is not actually tied to git, it has no concept of repos, just protocols (http/https) and hosts. Although I have not run this experiment, I'm reasonably certain that one could start talking to an existing git credential helper today. I'm less certain, but curious, if that credential manager were something that knew how to talk to GitHub - for example - GCM Core - then you could authenticate to GitHub Packages today (since it knows how to authenticate to GitHub for git operations).

(I suspect that GCM Core matches on github.com, not packages.github.com, but I could be wrong.)

Assume for a minute that GCM Core is actually suitable for this task. Certainly, I concede that this isn't just "done". There is still work needed in every CLI to spawn a process and talk to it. And any registry that isn't GitHub, GitLab, Azure or Atlassian managed will need to be added to GCM Core to work. But I also don't think that it's more complicated on the face of things.

[ethomson]

(Also note that oauth is not exactly my expertise, so I may be radically misunderstanding the work necessary here and there's actually no changes to be made to servers that speak oauth, even if they don't do device claims today.)

[isaacs]

The work required on the npm CLI is very minimal. Yarn and pnpm would likely have to implement it from scratch, but npm-profile is already a thing that exists and they can use (or copy) if they wish.

For the harder part of "update all the CLI installations" portion, and making it work with every registry under the sun, I'd suggest that we:

• first try oauth2 device flow
• maintain backwards compatibility with our current WebLogin and "basic auth to get a token" approaches for the indefinite future (perhaps mark as deprecated, suggest registries move to the newer approach etc.)
• rip out the lib/auth/*.js sso stuff, which is kludgey at best, subject to race conditions and security vulnerabilities if implemented imperfectly, and (afaik) only supported on the legacy on-prem form of npm Enterprise (which we don't support any more anyway).

Then it becomes an iterative process to get it into yarn and pnpm clients, and into verdaccio/gh packages/artifactory/nexus/... on the server side. Implementation should be pretty straightforward for anyone already doing oauth2 for other purposes.

As for using git for credentials, I think that's a great idea to explore as a place to stash tokens more securely, and I'd also love to explore the idea of communicating with the registry over an SSH channel where possible. But these are much more involved (and somewhat orthogonal) ideas, as I understand it (which I might not, fully).

[ThisIsMissEm]

@isaacs I'd be inclined to agree with this statement:

But these are much more involved (and somewhat orthogonal) ideas, as I understand it (which I might not, fully).

If in the future we want to add a separate npm-credentials-manager type executable that's responsible for doing everything related to handling credentials and getting access tokens, then that's a new RFC/discussion. For now, the goal is to simplify and standardise what's a pretty much pre-existing feature.

The implementation approach matches what I had in mind: write RFC, update npm-profile and npm, then other clients, then registries where appropriate. The execution from the CLI would be:

1. Try oauth2 device flow
2. Try WebLogin
3. Fallback to basic-auth for getting a token

As for SSO in lib/auth/*.js that's great to know it's deprecated! Perhaps we can remove support for it entirely in the next major version of npm, given it is now unsupported?

For pnpm/yarn, there is — iirc — a reason as to not just directly re-use libnpmprofile, which was to do with the HTTP client and logging, maybe a good idea would be to make those configurable in libnpm, as to encourage more code-reuse?

[isaacs]

As for SSO in lib/auth/*.js that's great to know it's deprecated! Perhaps we can remove support for it entirely in the next major version of npm, given it is now unsupported?

Yes. It prints a deprecation warning when used now, and will be gone entirely in npm v8.

a reason as to not just directly re-use libnpmprofile, which was to do with the HTTP client and logging, maybe a good idea would be to make those configurable in libnpm, as to encourage more code-reuse?

npm-profile is not particularly opinionated about logging. It only depends on npm-registry-fetch, which may be given a log object with notice and http methods like npmlog provides. But if you don't give it a logger, it'll just use it's silentlog.js logger which noops all the methods. npm-profile itself logs by using process.emit('log', level, ...message), which npmlog picks up by default and prints out. There is legitimately some ironing out to do with logging in the npm cli stack, but it's not as if this particular lib would require anyone to use npmlog specifically.

[ethomson]

If in the future we want to add a separate npm-credentials-manager type executable that's responsible for doing everything related to handling credentials and getting access tokens, then that's a new RFC/discussion. For now, the goal is to simplify and standardise what's a pretty much pre-existing feature.

I'd like to back up a little bit, because again, I think that we're talking about technical implementations (the RFC) before we've clearly defined our goal, and how we're going to measure the success of reaching that goal (the product discussion). Looking at #7, you have identified one potential solution. This discussion exists to identify the path forward to meeting our goal.

Our goal isn't to implement oauth in the npm CLI, because if we go add oauth to the npm 7 codebase then we will have met our goal but not necessarily helped very many people.

I think that we can start with a really high level goal statement - we're trying to simplify authentication from a CLI to registries that aren't npmjs.com. (I think that this is uncontroversial, but I think that starting here is important to ensure that we're unified.)

From there, I think that we need to define:

• What CLIs are we targeting with this? npm 7 and yarn 2 are seeing new feature development. But most people are using npm 6 and yarn 1; is there somebody willing to do the work in those clients and ensure that it gets merged? If so, what is the appropriate amount of code that those projects will accept? My understanding is that one of them is working largely without a maintainer (though I may misunderstand), so the size of the code churn may be impact the maintainers desire to accept a contribution. Which will inform the technical decision making.

• What registries are we targeting with this? You've enumerated GitHub Packages and Verdaccio. What are the "must haves" here? Which registries support oauth currently? Which registries don't do oauth but are supported by the npm CLI anyway? Of those registries, do other CLIs support that custom auth flow? If not, does that matter? This will also inform the technical decision making.

In other words: if our goal is to improve the lives of npm 7 customers using Verdaccio, then I think that we have a pretty clear picture of what we can do to get there. But I think that our goal should be bigger than that.

If we want to improve the lives of npm 6 users of Verdaccio, or yarn 1 users of npm Enterprise, then this decision making will guide the technical implementation.

As for using git for credentials, I think that's a great idea to explore as a place to stash tokens more securely, and I'd also love to explore the idea of communicating with the registry over an SSH channel where possible.

Note that this is not using git for credentials. It's an example of an external process. Git moves the authentication handling out of process. This may (not necessarily is) a model that we want to explore because:

1. Every CLI can share a common external auth process
2. Building a mechanism to talk to an external auth process may be less work for each CLI than building support for oauth. This may be beneficial for projects that are not in heavy active development, but have the lion's share of usage despite that.
3. Updates to the external auth process can happen out-of-band of the CLI updates. You're stuck on npm 6 or yarn 1 for some reason, but you want to be able to authenticate to some new system? That's a change that's possible.

My point isn't that we should do this. My point is that we need to decide what we want before we decide the technology that gets us there.

[ThisIsMissEm]

I think that we can start with a really high level goal statement - we're trying to simplify authentication from a CLI to registries that aren't npmjs.com. (I think that this is uncontroversial, but I think that starting here is important to ensure that we're unified.)

This is incorrect. This comes from the npmjs registry having a proprietary method for doing browser-based authentication (WebAuth), which is often simpler for developers to perform and more secure. The goal is to provide that same level of ease for non-npmjs registries.

Obviously, we could just do an RFC that standardises the WebAuth method from npm & the npmjs registry, however, as there is already an existing wildly established standard which is almost identical to the WebAuth protocol from npmjs.com, it makes sense to use that standard. Making the OAuth Device Code Grant Flow the standard method for authenticating with registries as humans, we'd be superseding WebAuth that npm & npmjs.com currently use.

So perhaps more correctly the statement is:

We're aiming to specify and implement a standard for doing authentication for humans between clients (npm, yarn 1, pnpm, etc) and registries (npmjs.com and private registries).

As for:

If so, what is the appropriate amount of code that those projects will accept? My understanding is that one of them is working largely without a maintainer (though I may misunderstand), so the size of the code churn may be impact the maintainers desire to accept a contribution. Which will inform the technical decision making.

Yarn 1 is still very much so maintained by the community. And I have already discussed this at length with the people directly involved in those projects.

This isn't about registries supporting OAuth. It's about a standard protocol for doing browser-based login from CLIs, which exists as a standard defined within the OAuth 2.0 specifications, as well as in the proprietary WebAuth protocol. It's literally taking one spec that clearly defines a bunch of endpoints and behaviours and going "yeah, that's what we're doing here already"

I truly respect the input from a product manager at Github on this discussion, but you are coming to the discussion very late. This is something that has already been discussed at length before Github acquired npm Inc.

What registries are we targeting with this?

All of them, when dealing with humans authenticating against them.

What CLIs are we targeting with this?

All of them, but personally, I have funding for both npm CLI v6 and yarn v1. It's a standard. Not a new feature.

If we want to improve the lives of npm 6 users of Verdaccio, or yarn 1 users of npm Enterprise

This doesn't remove any authentication mechanisms, but it is designed to supersede them. If we call npm 6 as a frozen codebase, then fine, to use this standard, you'd have to use npm 7, and npm would likely push people to upgrade to npm 7. As for yarn 1 users of npm Enterprise, well, I will be building the yarn 1 support for this standard, so if npm Enterprise wishes to implement the standard, then they can use it there too.

talk to an external auth process may be less work for each CLI than building support for oauth

Have you read the existing discussion, this isn't "building support for oauth" it's "implementing a very small specific subset of the oauth standard that happens to match very closely to an existing proprietary standard, such that other registries & clients will adopt it"

Furthermore, a "external auth process" is much more complicated to implement. What's the binary called? how's it configured? how's it used by all clients? does each client have their own? their own protocol too? — seriously, way too many questions in that path.

That third point there isn't particularly relevant, as why should we need more than one standard for authenticating with registries via the browser for humans? "Visit this url with this unique code, show login form, and optionally permissions form if needed, return token for authentication", if the registry delegates auth to a third-party, e.g., verdaccio to gitlab, it's just a matter of initiating and completing the gitlab oauth protocol, and then once complete, having verdaccio return an authentication token.

I don't mean to come across as forceful or argumentative, but these are points that are being raised very late in the conversation, and seem like a major step backwards, after I've already done a lot of work getting people on board with the idea of having a standard way for humans to authenticate between CLIs and registries.

[arcanis]

Yarn 1 is still very much so maintained by the community. And I have already discussed this at length with the people directly involved in those projects.

Of note: we discussed it in January and I already mentioned back then that Yarn 1 was kind of in a feature freeze. Since then we have released the next major (plus three minors, and we're soon gonna start work on the 3.x), and all of our resources have been diverted to it. I'm not aware of anyone else shipping any improvements to Yarn 1 since then, apart occasionally me, and only to improve the migration to Yarn 2 🙂

I'm still supportive of this workflow, but as far as I'm concerned, it'll be Yarn 2+ only.

I think that we can start with a really high level goal statement - we're trying to simplify authentication from a CLI to registries that aren't npmjs.com. (I think that this is uncontroversial, but I think that starting here is important to ensure that we're unified.)

I'm not sure that's the goal - my understanding is that this feature would make it safer to interact with publish registries. The npm registry being what it is, most publish workflows happen there, and thus the primary target for such an auth API would be the npm registry.

I believe the Verdaccio reference is mostly to exemplify that this Browser Auth API, would be a documented, standard, endpoint-based API, that third-party registries would be able to implement without reverse engineering (and thus not an opaque package like npm-profile).

[isaacs]

Yarn 1 was kind of in a feature freeze.

npm 6 is in a similar state. Since npm-profile didn't change much between npm v6 and v7, it's likely that we could backport this once implemented, but the public registry at least will have to maintain backward compatibility with the "basic auth to get a token" style of login for the foreseeable future.

and thus not an opaque package like npm-profile

npm-profile will be the reference implementation that we support, and any clients are free to use it. But yes, it will be something with the IETF seal of approval on it, which makes it easier for third-party implementers to feel safe relying on it.

[ThisIsMissEm]

I'm still supportive of this workflow, but as far as I'm concerned, it'll be Yarn 2+ only.

@arcanis oh! I must've misunderstood. I can secure funding to develop this for Yarn 1.x

I believe the Verdaccio reference is mostly to exemplify

At the time when I initially did the RFC, I was working at a company where we used verdaccio, and authenticating was tedious and difficult. Now I'm working with a client who use Github Packages, and authenticating is still tedious and difficult. (e.g., people forgetting to enable SSO on their tokens, or not entering their public github email address). Hence, giving people browser based login will remove all these issues and simplify everything for everyone.

the public registry at least will have to maintain backward compatibility with the "basic auth to get a token" style of login for the foreseeable future.

@isaacs yeah, I think all registries will have to support basic auth tokens, but ideally those should be for machine usage, not human usage. i.e., if you've an interactive tty, then you should be encouraged to switch to browser-based auth.

[ethomson]

I don't mean to come across as forceful or argumentative, but these are points that are being raised very late in the conversation, and seem like a major step backwards...

I don't think that you're being forceful or argumentative, but I do think that we have a bit of an impedance mismatch in our discussion... sometimes that's the tyranny of using text? It's slow and low-bandwidth. I'm happy to jump on a call if you want to chat higher bandwidth.

And just in case I wasn't clear: this work needs to happen. Yes, the CLIs should be able to easily authenticate to alternate registries. No, Verdaccio shouldn't implement WebAuth to make that happen. But I also want to make sure that this will support (for instance) GitHub Packages and Artifactory.

I've already done a lot of work getting people on board with the idea of having a standard way for humans to authenticate between CLIs and registries.

I appreciate that, and I'm not trying to minimize the work that you've done or derail it. And indeed, I see a lot of excitement around this from the CLI side of things, which is great. But it's also only one side of the work that's needed; what I'm wondering is about the registry side. I don't see that reflected in the conversation on the RFC. (With the exception of Verdaccio, which is why I was using it in the examples.)

When I asked about what registries needed to support this:

All of them, when dealing with humans authenticating against them.

I don't think that our success metric should be "all of them", that's just not something that we will or should try to achieve.
What I'm trying to understand is:

• Which registries support oauth device flow today and so that this will just work? 🎉
• Which registries do not support oauth device flow today but we want to support with this work?

Question one is easy and an obvious win for us. By adding this to the CLI, voila! 🎉

It's question two that I'm interested in - does GitHub Packages support oauth device flow? I think it might(?) but if it doesn't then that's not something that we should necessarily assume can be supported. Same with something like Azure Artifacts, which uses Azure's auth system and - again I think might(?) support device flow already - but if it doesn't then that's an even bigger hurdle for support because Azure's auth mechanisms are big and complex, and changing them is not trivial.

That's why I'm asking what success looks like here. I don't think that we can assume that registry vendors will necessarily jump to support this if they don't already. I'd like to get clear what will be supported if we do this work, and what registries will adopt support here. Because if the answer is that 100% of registries support it out-of-the-box or will soon, then adding support in every CLI is clearly a win. But if the answer is that 0% will ever support it, then there's no point in doing any work in any CLI.

But it's somewhere between 100% and 0%, and I'm wondering what that number is, because that's what should dictate the strategy here. For example: the on-premises version of npm Enterprise will never support this, and knowing that may change our implementation. (In the case of npm Enterprise on-premises, no, it certainly shouldn't.)

But I'm also asking because this is the part that I can help with, given that I manage three registries and work closely with people who manage two others (GitHub Packages and Azure Artifacts, which is why I mentioned them earlier). I can pretty easily talk with the product managers over there to encourage them to add this support and understand if / when they're able to.

[ThisIsMissEm]

I don't think that you're being forceful or argumentative, but I do think that we have a bit of an impedance mismatch in our discussion... sometimes that's the tyranny of using text? It's slow and low-bandwidth. I'm happy to jump on a call if you want to chat higher bandwidth.

I already have a call scheduled for 6pm Berlin time tonight with @MylesBorins. Have suggested you join.

And just in case I wasn't clear: this work needs to happen. Yes, the CLIs should be able to easily authenticate to alternate registries. No, Verdaccio shouldn't implement WebAuth to make that happen. But I also want to make sure that this will support (for instance) GitHub Packages and Artifactory.

Agreed, this proposal doesn't remove any of the existing authentication mechanisms, but proposes a new standard for authenticating that should be considered to supersede the earlier authentication mechanisms when dealing with humans, most likely we say "Basic Auth with static token is now considered to be an automation interaction, rather than a human interaction"

So we'd have two strategies for authenticating:

• Humans — Browser Based with OAuth Device Code Grant Flow (this RFC)
• Robots/Automation/Legacy — Basic Auth + static token

This would be a clearly defined part of the Registries API, so all registries can implement and conform to it, allowing better interoperability. Currently all registries are basically. reverse engineering each other, leading to inconsistent functionality and confusing user experiences. I would like to see the Registry API Specification be open-source and not implementation driven, this RFC could be a first step towards that, but it is a wider conversation to have, which I think will be very welcome from the community.

When I asked about what registries needed to support this:

All of them, when dealing with humans authenticating against them.
I don't think that our success metric should be "all of them", that's just not something that we will or should try to achieve. What I'm trying to understand is:

By "all of them" I'm meaning if we make this a standard part of the Registries API, then all registries should ideally implement it, and if they want implement some other form of authentication for machines (currently basic auth + token). It's just like "all registries" need to support the registry API (n.b., that is outdated, but is the closest documentation available)

Which registries support oauth device flow today and so that this will just work? 🎉

None currently, as it's a new strategy based on the similarities between the OAuth Device Code Grant Flow and WebAuth — we don't want registries implementing the proprietary WebAuth, so instead the RFC is a proposal that we'll adopt a web standard that does something that is functionally the same at almost all levels (I don't think there's any major differences)

Which registries do not support oauth device flow today but we want to support with this work?

I would like to see support in Github Packages (my funding to work on the client implementations may be contingent on this, as the organisation offering potential funding uses Github Packages), Verdaccio would benefit heavily from supporting this, and ideally we'd move the npmjs.com registry to this.

The goal is to make a standard for the API that both clients and registries can agree on, and then start implementing, so it's not about doing the work in either place just yet, we just need the standard there such that both parties go "yes, let's implement this"

I don't think that we can assume that registry vendors will necessarily jump to support this if they don't already.

They will if it's a standard and makes their user experience better. They've already had to implement how many other authentication mechanisms in order to be compatible with clients and other registries, so if there's a new standard then adopting it makes a lot of sense.

Whether clients or registries implement first is a chicken and egg problem, we need a standard API first, before either will agree to implement. That's what this RFC is about.

I can secure funding to implement in Yarn 1.x and npm 6, I would be open to accepting funding to implement in Verdaccio, though it's not something that I'm currently using.

the on-premises version of npm Enterprise will never support this

Is npm Enterprise supported and actively developed? If yes, then ideally they would support this standard, as it'll make so many things easier. I think there is a migration plan here for npm Enterprise's sunset: https://docs.npmjs.com/enterprise/migration — therefore I think it's irrelevant to this conversation.

I'm also asking because this is the part that I can help with, given that I manage three registries and work closely with people who manage two others (GitHub Packages and Azure Artifacts, which is why I mentioned them earlier)

Yes! This is where we need support and agreement on standardisation. Once we have this new RFC ratified and part of the standard Registries API Specification, then we'll definitely desire both those teams implement that standard API.

The first step is a standard API for registries, then we can discuss implementations.