crypto: change withheld code for IdentityBased share strategy

[BillCarsonFr]

Change the withheld code for the IdentityBasedStrategy from WithheldCode::Unauthorised
to WithheldCode::Unverified.

• Public API changes documented in changelogs (optional)

Signed-off-by:

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.49%. Comparing base (d254217) to head (2bb0c50).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3985      +/-   ##
==========================================
- Coverage   84.54%   84.49%   -0.05%     
==========================================
  Files         266      266              
  Lines       28478    28478              
==========================================
- Hits        24076    24063      -13     
- Misses       4402     4415      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[stefanceriu]

Looks good to me but can we have an explanation as to why this happened?

[BillCarsonFr]

Looks good to me but can we have an explanation as to why this happened?

You can find more here https://github.com/element-hq/element-web-rageshakes/issues/27055#issuecomment-2344092110

TL;DR It's for the new invisible crypto, and I was not sure of what withheld code would be the best to return (unauthorised, unverified, a new one?). After some discussion with @richvdh we decided to use m.unverified for now (also there is proper UX for that code)

[richvdh]

Even more context:

m.unverified could be considered inappropriate because that code means that the sender is only sending to devices/users that the sender has verified (eg via emojis). That is not, strictly speaking, the problem here: the sender does not care that they have not done an interactive verification; they do care that the device owner has not done a verification.

Nevertheless, it feels less bad than co-opting m.unauthorised. The spec isn't very explicit, but the intention with m.unauthorised is that it be sent in response to a key-share request.

Ideally, we would have a different withheld code, more relevant to this case, but doing so would require spec changes and a bunch of work on the recipient side to handle the new code.

Using m.unverified feels like a pragmatic solution.

[richvdh]

LGTM otherwise