acl: Extend BearerToken message with issuer field

[cthulhu-rider]

No description provided.

[carpawell]

What does it solve? It can be trusted only if we trust the signature (know key/signature -> container owner (and only the owner as it is said in this PR) relation).

[cthulhu-rider]

@carpawell problem is mentioned in the commit

It can be trusted only if we trust the signature

we can be different, needs may vary from app to app. Apps like gateways dont (should not) do validation on their own, at the same time, they could have a need to access the field

[roman-khimov]

If it's present we can fetch additional data from contracts or in any other way, we can check public key corresponds to it. The way I see it now is we basically have two ways to solve ID (user) issues:

• map every account to some script via neofsid
• replace public keys with proper verification scripts in every case we have a signature

This makes the first option easier.

[carpawell]

Apps like gateways dont (should not) do validation on their own, at the same time, they could have a need to access the field

No validation -- GW may consider any issuer, the issuer is not proofed.

If it's present we can fetch additional data from contracts or in any other way, we can check public key corresponds to it.

The same way public key can be sent to a contract to get owner?

[roman-khimov]

The same way public key can be sent to a contract to get owner?

That's different to me. ID is more abstract than a key, it doesn't imply any specific validation scheme on its own.

[cthulhu-rider]

No validation -- GW may consider any issuer, the issuer is not proofed.

dont see any problem with this. GW is GW, it just transmits data back and forth b/w protocols. Self validation is not really good behavior for such entity