Support Passbolt v5 API

[speatzle]

Full Support for Resource Types, Encrypted Metadata and the v5 API.

This will Most likely mean Breaking the go-passbolt API by just exposing a Maps in the Resource Struct to Support Resource Types and Encrypted Metadata Properly.

https://www.passbolt.com/blog/the-road-to-passbolt-v5-encrypted-metadata-and-other-core-security-changes-2

https://docs.google.com/document/d/1yuucNxUJYcYFqsLUORTRqd4HZs1vROmtQQ6stGbdwpU/edit?pli=1&tab=t.0

[Nelwhix]

Hi @speatzle, I would love to work with you on this. When do we start?

[speatzle]

Hi, Sorry for the delay.

Thank you for your interest in helping out.

The big thing that v5 brings is encrypted metadata, but its probably also gonna expand on the Resource Types introduced in v3.

Back then i was already struggling to find time so instead of Properly implementing Resource Types i just made it work for the few types that exist with the existing go-passbolt Resource struct.

Since Encrypted metadata is going to change the Format of a Resource again i don't think we can just Expand the Struct anymore.

The current plan i have in mind up would be to have just the few unaffected fields Directly in the Resource Struct (id, folder_parent_id, ???) and have one map for the Metadata and one map for the Secret data which we both check against the Resource Type Json Schema from the Server.

We could then have Generic Resource Type variants which expose helper functions to get the Various values of the fields the Resource Type in Question has.

This would allow for Ergonomic programming with the usual Resource Types and still allow for all custom or new and currently unknown (to go-passbolt) Resource Types to be used.

Since all of this has just been in the Back of my head since the v5 announcement i would appreciate any suggestion / improvements on these ideas or alternative solutions.

[Nelwhix]

I think your idea is sound. When you are ready to start just create issues and we will tackle them together