The API is expanded by an optional autoSelectionPrincipal, which is the textual representation of the dapp specific user principal of the user to be re-authenticated. If this principal is known to Internet Identity and the matching identity was most recently used on the dapps origin then the identity will be selected automatically such that the user will be directly prompted to authenticate using the passkey as the only interactive step of the whole flow.
Thanks a lot for the feedback. Yes, the rendering in the dashboard seems to be incomplete, we have relayed that feedback to the dashboard team. This is due to changes in the proposal types related to system canister management.
As for this particular proposal, I would suggest verifying the information using the NNS dapp.
Hi @frederikrothenberger . Another question about payloads. In the latest II update proposal (132373), wasm_module_hash in the payload is derived from the production version of the module, whereas arg_hash is derived from the archive version. Is this how it’s meant to be or is there an unintended inconsistency here?
Is there any documentation covering the payload content for these proposals (and other similar ones) that reviewers can refer to? I’ve found outlines of proposal types in a few spots but nothing quite as specific as this.
The reason why the arg contains the archive hash is because we wanted to be able to upgrade both II and its archive canister with a single proposal.
So the II canister owns the archive and has the hash of the wasm configured that it should be updated to. The wasm for the archive (that matches the configured hash) is then supplied separately.
We plan to also record a more in depth video on how to verify II upgrade propsals in the near future.
