A fully managed end-to-end service for digitally signing code, documents, and applications. (formerly Trusted Signing)
Azure Artifact Signing Accounts - Identity Validation - could this flow be streamlined please?
Sharing this in case it helps anyone else working through account verification for build signing.
I ran into several issues with the AU10TIX Verified ID flow that made the process much harder than it needed to be. Support options were limited, and the error messages did not provide enough information to diagnose what was going wrong.
A few things that would significantly improve the experience:
- The ID capture screen should clearly display an ID-shaped reticle or overlay. This appears to be important for properly positioning the document, but the overlay did not display for me on iPhone. Instead I was repeatedly met with "No ID detected"
- Browser/device compatibility should be documented. In my testing:
- iPhone + Safari: failed
- iPhone + Chrome: failed
- Android + Chrome: succeeded
- iPhone + Chrome: failed
- iPhone + Safari: failed
- ID requirements should be disclosed before verification begins. In particular, I discovered only after completing an attempt that the ID needed to contain my address, despite the ID without address flow in AU10TIX having the extra step of scanning a mailed document with my address. If certain ID types or required fields are not accepted, those requirements should be validated or clearly communicated before the user proceeds through the entire capture process.
- Microsoft and AU10TIX should align the requirements presented to users. Ideally, the flow should prevent an obviously ineligible verification attempt from starting rather than allowing the user to complete the process and then requiring an entirely new attempt.
The underlying verification requirement is understandable, especially for something security-sensitive like build signing. The frustrating part is that unnecessary implementation and documentation problems turn what should be a straightforward identity-verification step into a device/browser compatibility exercise.
Clear prerequisites, explicit compatibility guidance, better validation before capture, and more actionable error messages would make this considerably less painful.
Thanks,
Robert