it seems reasonable to me that commits with non-authorized data would not be shared to other role-holders before first being returned to the party that can do the authorization.

Even if it does, that would still be fine as blame can clearly be laid at the party claiming a role and then not signinf off on the data, either because:

1. if you disregard the data then there is unfullfilled requirements, or
2. if you consider the data then there is a party that hasn't yet signed

So it comes down to the question of "did entity X call signInivitation()?"

If they did, but didn't sign the other data, then that data is to be disregarded (treat it as it simply wasn't there). If they didn't, then treat treat the invitation as non-complete as a role requirement still remains to be fullfilled.

Kuldeep (d96fd422) at 16 Mar 10:55

Kuldeep (85fa7d53) at 16 Mar 10:55

... and 1 more commit

Kuldeep (d96fd422) at 16 Mar 08:10

Kuldeep (8f331af2) at 16 Mar 07:55

Kuldeep (68cdf949) at 16 Mar 07:55

... and 1 more commit

approved now so that I can see in the log that I have reviewed and approved this earlier and can re-review only the changes.

I assume these either are no longer needed, or have been moved elsewhere prior to this MR.

this creates two storage adapters.

I assume it's better to do "const storageAdapterPromise = createStorageAdapter(...);

then await expect(storageAdapterPromise...

./ doesn't seem like a temp directory.

maximum of 1 here, but checks in this MR compare against both >1 and >2

.... 🤔 if libauth is handling bigints and uint8arrays, and we are going to use that standard, then... why do we need a separate extended-json package?

This was me being dumb.

It uses a replacer https://github.com/bitauth/libauth/blob/master/src/lib/format/log.ts#L27

If I understand correctly, this will still fail on bigints due to libauth currently still using base JSON.stringify.