refactor: make Statement.Value a json.RawMessage to get rid of custom (un)marshallers

[dschmidt]

Proposed Changes

• add a custom json Marshaler for sdk.Statement that works similar to the Unmarshaler and handles json structured values

If you agree with this change, I'm happy to add tests.

I assume it's a good idea to try to decode the value to make sure it's actual json. I just wasn't sure whether we should return an error if not or if we should just use the value as string. Opinions?

Checklist

• [ ] I have added or updated unit tests
• [ ] I have added or updated integration tests (if appropriate)
• [ ] I have added or updated documentation

Testing Instructions

[dschmidt]

I've updated the PR with a change to Assertion.GetHash()` because after an update of the SDK the verification of the assertion signing failed.

Tbh it feels even messier now than before. Why don't we just make Statement.Value a json.RawMessage? That should simplify everything a lot...

[jrschumacher]

/gemini review

[jrschumacher]

I've updated the PR with a change to Assertion.GetHash()` because after an update of the SDK the verification of the assertion signing failed.

Tbh it feels even messier now than before. Why don't we just make Statement.Value a json.RawMessage? That should simplify everything a lot...

This makes a lot of sense. Do you want to take that change otherwise I'll add it to our backlog.

[dschmidt]

@jrschumacher ping? :)

[jrschumacher]

@dschmidt we're reviewing this with some additional changes to assertions that are coming. We should be ready for a decision this week.

[dschmidt]

Alright, sounds perfect!

Happy this isn't forgotten :)

[dschmidt]

So .. any update?

[pflynn-virtru]

Draft PR here: https://github.com/opentdf/platform/pull/2687

There is a WIP ADR. It will hold the decision on this refactor.

We are heavily considering keeping the Statement.Value a string in all SDK implementations.