Bearer token issuer key to owner transformation

[alexvanin]

Kudos to @cthulhu-rider

S3 Gateway uses Issuer() public key of bearer token to obtain user ID of the token owner. This token owner is set as owner of all produced objects. The same way Issuer() public key of session token is used to create new bucket. Meanwhile, NeoFS supports (at least partially) public key binding with owner, see neofsid contract.

Object

Consider owner with key X which produces Foo user ID and bound key Y which produces Bar user ID. Bearer token may be issued with the key Y. Then all produced object will have Bar in owner field. We need to decide if this is expected behavior for S3 Gateway.
Additionally:

• owner field is mostly informative in objects and doesn't involve in any ACL checks; it is only checked when container has sticky bit in basic ACL
• object owner field is not processed by S3 (check?), so while ACLs on NeoFS side are okay, then we don't care about owner field from S3 point of view.

Possible solutions:

• ignore it and keep setting Bar user ID in produced objects
• find original user ID from Issuer key (how?)

Container

The same can happen with session token to create new bucket/container. It is a bit more complicated, because container owner is involved in ACL checks.

Questions there: how we expect NeoFS to process container ownership when it is created with a session token signed by Y key. I see two options there:

• at container creation stage client should set Foo as owner and Alphabet nodes check connection between Foo user ID and Y key; if they are related, approve container,
• create container with Bar owner and check ownership during ACL checks.

[alexvanin]

We can discuss and make a decision there. However the issue is going to be blocked until NeoFS fully supports bound keys.

[cthulhu-rider]

Seems like we can do nothing with it in multi-bucket operations (like ListBuckets): bearer token doesn't contain specific issuer ID, so we can only resolve it from signing key.

[roman-khimov]

Obsoleted by nspcc-dev/neofs-api#266 (which is already in the protocol). And nspcc-dev/neofs-api#305 will make it totally irrelevant.