Distribution options for persistence & discovery #10
Conversation
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
docs/distribution/README.md
Outdated
| * Based on the artifact type: `manifest.config.mediaType: "application/vnd.cncf.notary.config.v2+jwt"`, role check may be done to confirm the identity has a signer role | ||
| * As registry operators may offer role checking for different artifact types, Notary v2 Signatures are just one of many types they may want to authorize | ||
|
|
||
| **Cons with this approach:** |
There was a problem hiding this comment.
Another con is inconsistency, similar to the case mentioned comment:
https://github.com/notaryproject/nv2/pull/10/files#r481223090
There was a problem hiding this comment.
I've lost track of which con I'd add to the list. @reasonerjt, can you comment the specific con so I can add? was it recursive signatures?
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
There was a problem hiding this comment.
@SteveLasker Thanks for putting this together and taking the feedback from #5; the examples here are now much more clear!
docs/distribution/README.md
Outdated
| GET /v2/<name>/manifests/sha256:90659bf80b44ce6be8234e6ff90a1ac34acbeb826903b02cfa0da11c82cbc042/references/list?page_token=1&page_size=10&next_page_token=<token> | ||
| ``` | ||
|
|
||
| The above specifies that a tags response SHOULD be returned, from the start of the result set, ordered lexically, limiting the number of results to `n`. The response to such a request would look as follows: |
There was a problem hiding this comment.
I don't believe there's any requirement for a particular ordering. (I'd prefer that we leave an ordering requirement out so that implementing services can choose to return ordered results or not.)
There was a problem hiding this comment.
Would this be a problem for a standard notary client to get different ordered results from different registries?
There was a problem hiding this comment.
Can we say that without an orderBy parameter, the results MUST return by __ order?
Or, should we have a set of required and optional orderBy values? I know search is the Achilles heel to these discussions, but I don't know how we get around it. So, what can we do to have something minimal?
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
SteveLasker
changed the title
Includes:
Persistence options
Reference linking options
Signature discovery options
Paging options
Signed-off-by: Steve Lasker stevenlasker@hotmail.com
This is the continuation of #5