Consider adopting RFC 9728 OAuth 2.0 Protected Resource Metadata

[kohtala]

RFC 9728 OAuth 2.0 Protected Resource Metadata now specifies the discovery of authentication server both before accessing the resource and in the WWW-Authorization header of the 401 response from a resource.

I believe this requires some additional specification on what to place in the metadata for a registry. For example the scopes_supported could be specified to use placeholders {namespace} and {repository} as supported by the registry.

[sudo-bmitch]

Thanks for sharing, it's good to have this on the radar. Because it's not compatible with current registry implementations that I've seen, this likely needs to be pushed off to a v2 of the working group effort.

Two downsides of this for registry implementations that I can think of:

• /.well-known is outside of the current /v2 path, which could break some installs.
• It adds an extra round trip to every unauthenticated request.

[kohtala]

You are welcome. Should this new RFC make into http server and client libraries, it would make more sense using the common implementation rather than having a custom implementation.

Meanwhile, the registry authentication could leave room in the specification such that registries can return the WWW-Authenticate resource_metadata parameter it they choose to implement RFC 9728. RFC 9728 5.1 allows combining resource_metadata with parameters from other specifications. If registry authentication allows the same, there would be no need for a second WWW-Authenticate header.

The RFC 9728 section 3 uses MUST for the the /.well-known/oauth-protected-resource/v2 path. I do not see why it is required nor how a client could know beforehand it is needed for a resource. The section 5 WWW-Authenticate resource_metadata parameter allows carrying any other URL to return the metadata. Not having the /.well-known/oauth-protected-resource/v2 breaks only metadata discovery before accessing the resource, which is likely to be the uncommon usage.

Beyond first unauthenticated request to a registry, the extra round trip would be needed only if the unauthenticated requests returned different resource_metadata URL. If URL is the same as on first request, cached metadata can be used following the HTTP caching behaviors. Client can cache the metadata persistently and might even have default metadata for common well-known registries hard-coded. I also considered some standard minimum metadata client could assume without requesting metadata, but that may be excessive optimization and cause more problems and restrictions on authorization servers than it is worth for the clients.

The RFC 9728 extends to other metadata beyond authentication. It can provide Terms of Service, policy, documentation, and human readable resource names, even in different languages. RFC also established IANA protected resource metadata registry for additional metadata, should OCI need it. It's anyway an OAuth metadata, so perhaps better not extend it's usage beyond that.

Before RFC 9728 makes it into OCI specifications, a welcome and a place to anyone who wants to implement it in their registry to share and discuss their technical choices might help avoid need for it to be left out (like /v2/_catalog in distribution spec) due to existing incompatible implementations.