I'll answer my own question in case it's relevant for others. I had use_frameworks! in my Podfile. Once I removed that and rebuilt the .bundle, it worked.

Hmmm, that UI looks very familiar (-: Indeed, and thanks again. :) Where in the mechanisms array have you placed your plug-in’s mechanism? So, i had place them all at the very end of the pipeline but after posting this I tried putting our mechanism after <string>builtin:login-success</string> and before <string>loginwindow:success</string> and that works. So I now have (mine being CustomAuthPlugin): <string>builtin:prelogin</string> <string>builtin:policy-banner</string> <string>loginwindow:login</string> <string>builtin:login-begin</string> <string>builtin:reset-password,privileged</string> <string>loginwindow:FDESupport,privileged</string> <string>builtin:forward-login,privileged</string> <string>builtin:auto-login,privileged</string> <string>builtin:authenticate,privileged</string> <string>PKINITMechanism:auth,privileged</string> <string>builtin:login-success</string> <string>CustomAuthPlugin:invoke</string> <string>loginwindow:success</string> <string>HomeDirMechanism:login,privileged</string> <string>HomeDirMechanism:status</string> <string>MCXMechanism:login</string> <string>CryptoTokenKit:login</string> <string>loginwindow:done</string> which seems to be fine though I don't know if that has other implications that I'm not yet aware of.

I forgot to mention that this only happens after logging out - it doesn't happen if the VM is rebooted.

Another follow-up. It appears that the Authorization Plugin isn't actually hanging at all. The entire auth pipeline appears to execute based on the logs and the fact that the SecurityAgentHelper-arm64 user that runs the pipeline has no running processes in the hang state. I've tried to killing off other processes to see if that gets us logged in, but with no success so far.

Thanks a lot for the quick response! I will follow-up using the guidelines in that post.

I should add: presentRegistrationViewController doesn't throw an error, it's just that the window is nil and we thus can't show anything.

Another update: I discovered that you can definitely use presentRegistrationViewController inside of beginUserRegistration if you have not already used it inside of beginDeviceRegistration. So what I'm now wondering is whether we're doing something wrong or it's that you get basically one shot at UI and you have to choose between device reg and user reg.

As I dug into this more, it looks the answer is to use loginUserName on the LoginConfiguration object. I haven't POC'd this yet, but it looks promising.

Thanks for the quick response. And I assume by general-purpose signing from 3rd party code you mean that Apple code might be able to do it, but we will not be able to accomplish it? You are correct that this is in the context of IDP work and so PSSO is definitely on our radar for this. We'll dig deeper into that. Thanks, Francis

Another question on this topic: would an ACME certificate, which can be hardware bound, be used during the system context prior to login?