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
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
