Distribution Specification #34
Assignees
Comments
|
Docker distribution spec: https://github.com/docker/distribution/tree/master/docs/spec |
|
It looks like @xiekeyang mentioned oci-discovery [1] in the F2F. And
@cyphar also has some work in this space with parcel [2]. Both of
those cover discovery and distribution (although oci-discovery has
protocol registries for ref and CAS engines [3,4]).
Also in the F2F minutes, @dmcgowan also pointed out a distinction
between *discovery* and a registry (e.g. see [5], where
oci-discovery's OCI Well-Known URI Ref-Engine Discovery protocol lets
an authority say “look up my images in this Docker registry”). Is
this initial distribution work going focused only on a registry
protocol, or is it also interested in discovery? From the F2F, it
sounds like @vbatts wants to focus on the registry, and continue to
punt on discovery?
[1]: https://github.com/xiekeyang/oci-discovery
[2]: https://github.com/cyphar/parcel
[3]: https://github.com/xiekeyang/oci-discovery/blob/6870be0b85b4615f10433b5d4aa33bd6246ca912/ref-engine-protocols.md
[4]: https://github.com/xiekeyang/oci-discovery/blob/6870be0b85b4615f10433b5d4aa33bd6246ca912/cas-engine-protocols.md
[5]: https://github.com/xiekeyang/oci-discovery/blob/6870be0b85b4615f10433b5d4aa33bd6246ca912/well-known-uri-ref-engine-discovery.md#example-1
|
@wking the conversation was around standardizing the registry protocol since it already the defacto standard and avoid using the standardization process for innovating on new protocols. Innovation on discovery can handle in tandem to standardization of the registry protocol and added later. My point was that discovery and registry are completely separate and do not need to be added together. Also keep in mind that while all existing clients today are using the registry protocol, there is no common way in which discovery is being done. In this case discovery should not require any changes to the existing registry protocol or implementations. |
That makes sense. The risk with specifying after getting widespread adoption is that you can't fix things anymore because the backward-compat cost is too high (like this and opencontainers/image-spec#24). And the risk with specifying before widespread adoption is that you don't know what needs fixing. Either way, the solution is to eventually cut a v2 spec, and that's fine. |
|
As a heads up @opencontainers/tob, here's a draft proposal for the distribution spec project: https://docs.google.com/document/d/15y0SBrrDFIEM7pnU-Oe3Y6pq-eTZfo0mk-k33cS2hR4/edit#heading=h.fs1oc6z7su0d We will let it simmer for a week or so to gather feedback before formalizing things on GitHub. |
|
minutes from the last OCI Dev meeting regarding the distribution spec: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2018/opencontainers.2018-01-10-22.01.html The plan is to work together on a proposal and present it to the TOB for vote, current thinking is that it won't be ready until after the TOB election on Jan 29th. |
|
The google doc has been open long enough and seems baked. I converted it to markdown and opened up a PR so we can continue/finalize the discussion there for a couple of weeks or so and than formalize a vote after the new @opencontainers/tob is formed: #35 |
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 26, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. So folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow. While I prefer off-the-shelf RFCs for HTTP auth, the Docker registry additions are small enough, and widely used. This change adds the client side of their specification to the new distribution-spec project. The docker/distribution repository also includes docs for scope [3] and the JWT token semantics [4]. The scope docs are borderline useful for clients, but I've left them out because clients can extract the required scope from WWW-Authenticate in 401ed responses: $ curl -IH 'Accept: application/vnd.docker.distribution.manifest.v2+json' https://index.docker.io/v2/library/docker/manifests/1.12.1 HTTP/1.1 401 Unauthorized Content-Type: application/json; charset=utf-8 Docker-Distribution-Api-Version: registry/2.0 Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/docker:pull" ... Clients can consider them opaque, so I've left them out of the distribution-spec project for now. If distribution-spec maintainers feel that clients could benefit by explicitly crafting their own scope strings, they can pull in the scope specification after the project forms. JWT token semantics [4] are part of the interface between the auth server and the registry. Clients can consider them opaque, so I've left them out of the distribution-spec project. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope language is from Stephen in [5]. The discovery scope language is from Derek [6]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/oauth.md [3]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/scope.md [4]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/jwt.md [5]: opencontainers#35 (comment) [6]: opencontainers#34 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 26, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. So folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow. While I prefer off-the-shelf RFCs for HTTP auth, the Docker registry additions are small enough, and widely used. This change adds the client side of their specification to the new distribution-spec project. The docker/distribution repository also includes docs for scope [3] and the JWT token semantics [4]. The scope docs are borderline useful for clients, but I've left them out because clients can extract the required scope from WWW-Authenticate in 401ed responses: $ curl -IH 'Accept: application/vnd.docker.distribution.manifest.v2+json' https://index.docker.io/v2/library/docker/manifests/1.12.1 HTTP/1.1 401 Unauthorized Content-Type: application/json; charset=utf-8 Docker-Distribution-Api-Version: registry/2.0 Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/docker:pull" ... Clients can consider them opaque, so I've left them out of the distribution-spec project for now. If distribution-spec maintainers feel that clients could benefit by explicitly crafting their own scope strings, they can pull in the scope specification after the project forms. JWT token semantics [4] are part of the interface between the auth server and the registry. Clients can consider them opaque, so I've left them out of the distribution-spec project. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope language is from Stephen in [5]. The discovery scope language is from Derek [6]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/oauth.md [3]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/scope.md [4]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/jwt.md [5]: opencontainers#35 (comment) [6]: opencontainers#34 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 26, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. So folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow. While I prefer off-the-shelf RFCs for HTTP auth, the Docker registry additions are small enough, and widely used. This change adds the client side of their specification to the new distribution-spec project. The docker/distribution repository also includes docs for scope [3] and the JWT token semantics [4]. The scope docs are borderline useful for clients, but I've left them out because clients can extract the required scope from WWW-Authenticate in 401ed responses: $ curl -IH 'Accept: application/vnd.docker.distribution.manifest.v2+json' https://index.docker.io/v2/library/docker/manifests/1.12.1 HTTP/1.1 401 Unauthorized Content-Type: application/json; charset=utf-8 Docker-Distribution-Api-Version: registry/2.0 Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/docker:pull" ... Clients can consider them opaque, so I've left them out of the distribution-spec project for now. If distribution-spec maintainers feel that clients could benefit by explicitly crafting their own scope strings, they can pull in the scope specification after the project forms. JWT token semantics [4] are part of the interface between the auth server and the registry. Clients can consider them opaque, so I've left them out of the distribution-spec project. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope language is from Stephen in [5]. The discovery scope language is from Derek [6]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/oauth.md [3]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/scope.md [4]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/jwt.md [5]: opencontainers#35 (comment) [6]: opencontainers#34 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 26, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope language is from Stephen in [3]. The discovery scope language is from Derek [4]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 29, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 29, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 29, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 29, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 29, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. I've also added Mike's library/busybox scoping example [8]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) [8]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 30, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. I've also added Mike's library/busybox scoping example [8]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) [8]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 30, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. I've also added Mike's library/busybox scoping example [8]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) [8]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 30, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. I've also added Mike's library/busybox scoping example [8]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) [8]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 30, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. I've also added Mike's library/busybox scoping example [8]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) [8]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 30, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. I've also added Mike's library/busybox scoping example [8]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) [8]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 30, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. I've also added Mike's library/busybox scoping example [8]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) [8]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainers-tob
that referenced
this issue
Jan 30, 2018
Docker's use of Bearer requires information beyond what's covered in RFC 6749 and 6750 [1]. Folks writing a client that will interact with a Docker registry that uses that auth approach will need a "Docker registry's 'Bearer' additions" spec to follow, but Derek believes the situation is salvageable with external work [2]. Also pin the docker/registry links to a specific version so the links will survive future docker/registry changes (including removing the docs after the OCI picks them up). As long as the TOB-selected version isn't far behind (how far will the spec move during a week of voting?), it should be easy for the new maintainets to catch up on any subsequent drift. The signing scope is from Stephen in [3]. The discovery scope is from Derek [4]. The content-management scope is from Stephen [5] and Liang [6]. This commit also add's Mike's interoperability statement [7], which mentions one reason for the OCI inclusion is the implementation-agnostic location where implementers can collaborating on a common specification. The project scoping is open to drift with the limits imposed by the TOB's scope table. If the TOB thinks subsequent drift is excessive, they are free to make further scope-table adjustments in follow-up proposals. I've also added Mike's library/busybox scoping example [8]. [1]: xiekeyang/oci-discovery#64 (comment) [2]: opencontainers#37 (comment) [3]: opencontainers#35 (comment) [4]: opencontainers#34 (comment) [5]: opencontainers#35 (comment) [6]: opencontainers#37 (comment) [7]: opencontainers#35 (comment) [8]: opencontainers#37 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
|
Just an update here, now that the new @opencontainers/tob is elected, I will be working on updating the proposal to get it in shape for a vote some time next month. Let me know if there are any concerns about the timeline. |
Closed
|
I kicked off the official project creation vote here for the OCI TOB to approve: https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/dU6uXM__ilU |
|
It looks like someone with WordPress access still needs to make the
approved scope-table changes [1]. @caniszczyk, I'm guessing that's
you?
[1]: https://github.com/opencontainers/tob/blob/fe745a3bdaaf68d173d68c13aa5eb62a4b507be8/proposals/distribution.md#frequently-asked-questions-faq
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the OCI F2F (https://docs.google.com/document/d/1rL4wiY6Q7R199wz0PBtbbPVjMo_3v2BpO6c1kItPTLw/edit), we discussed kicking off a distribution specification project, based on the Docker distribution spec: https://twitter.com/chanezon/status/938845534466596864
We will have to go through the official OCI channels, which involves a project proposal to the @opencontainers/tob.
The text was updated successfully, but these errors were encountered: