[Standards] NEW: XEP-0401 (Easy User Onboarding)

Jonas Wielicki jonas at wielicki.name
Thu Feb 22 07:50:35 UTC 2018


On Mittwoch, 21. Februar 2018 19:42:19 CET Georg Lukas wrote:
> * Jonas Wielicki <jonas at wielicki.name> [2018-01-25 15:57]:
> > > However, then we need to define how the client can determine whether
> > > this Data Form is a PREAUTH compatible form, and whether the user is
> > > still required to add more content.
> > 
> > This can easily be done. Just specify the field @var. If the form has a
> > field with that specified @var, hide it from the UI and insert the
> > preauth token automatically on submit.
> 
> This is not overly complex logic, but it requires a full data forms
> display in the client, and then manipulation of the form before display,
> plus addition of a hidden field when sending the response. And then we
> also have to solve the i18n issue with the field names.
> 
> The alternative would be to perform a full mapping of the returned form
> fields to 'username', 'password', 'token' [, 'email'], and to display the
> client-intergrated original account creation dialog if these were the
> only fields that were sent in the form.
> 
> But we need to extend the IBR flow anyway, so I don't really see a
> compelling reason to use data forms here as opposed to an additional XML
> element in the 'jabber:iq:register' block.

I understand, and what you say (finally, I think you tried to express that 
multiple times, but I didn’t get it) makes sense to me. I wonder whether it 
still might sense however to use a Data Form to have a specified way how 
services can extend the form with additional fields.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180222/00337387/attachment.sig>


More information about the Standards mailing list