[Standards] Identifying username and password fields during Extensible IBR (XEP-0389)

Hi everyone! I've been trying to design a "verify with one-time code during registration" flow using XEP-0389 (Extensible In-Band Registration). Specifically, this is for registration on the server itself (not on an external component) and I'm using the jabber:x:data challenge. However, I realised there's no standard way for the client to know what its username and password is once the registration is complete. The old IBR spec (XEP-0077) uses special <username/> and <password/> fields which the client can automatically save to avoid the user having to re-enter it. Since "username, password, and some additional verification step" sounds like a common use-case for IBR, should this be added to the spec in some way? Some options: 1. Extend the jabber:x:data challenge to say something like: servers MUST NOT use var='username' and var='password' for anything other than username and password, and clients MAY save those values locally if present to avoid forcing the user to re-enter them. 2. Alternatively, extend the jabber:x:data challenge to say it can optionally include <username/> and/or <password/> tags as siblings to the <x xmlns='jabber:x:data' type='form'> form itself. 3. Same as (2), but with a new challenge type to keep things simple for those who actually want just an ordinary Data Form. 4. Define a new challenge type something like jabber:iq:register consisting of only <username/> and <password/> fields from 0077 (not sure what to do about <email/>, but I don't see a need for it). This is different from just using 0077 directly because the server can issue this challenge as part of a flow *along with* other challenges like jabber:x:data or jabber:x:oob. The disadvantage is the server would have to issue an extra challenge (once for the username/password, and again for the email address or whatever other data it wants like phone number) rather than combining them in one form/challenge. However, this approach is arguably cleaner as it doesn't mix different kinds of things (data forms and specific standardised fields) together. Let me know what you think of the above. I hope I didn't miss something entirely! If there are existing implementations of XEP-0389, it would be helpful to see, although I don't find any on the XMPP software list. Best, Badri