[Freeipa-devel] [PATCH] 531-541 OTP UI

[Nathaniel McCallum]

On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote:
> On 24.2.2014 15:31, Nathaniel McCallum wrote:
> > On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote:
> >> On 21.2.2014 20:00, Nathaniel McCallum wrote:
> >>> Is it possible to do something more intelligent for the key and date
> >>> fields in the add-token UI?
> >>>
> >>> Date fields are currently just a text box. Is there any sort of calendar
> >>> we could use here? If not, I'm still unsure of what the format should be
> >>> for this field.
> >>
> >> It's the format you chose :), try to fill it in CLI, you will have the
> >> same proble. From API level it's just string, from LDAP it's generalized
> >> time.
> >
> > Is there a better option? I'm open to suggestions.
> 
> As I mentioned below, it's being implemented. The datetime patches will 
> be send separately. The core OTP UI patches should not be blocked by them.
> 
> >
> >> I've an UI patch prepared where you can write it in ISO format, with a
> >> validator attached to it, so user will be noticed about the format, but
> >> it's waiting for:
> >> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html
> >> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html
> >>
> >>>
> >>> The key field should probably have a note indicating that it is Base32
> >>> encoding. It would also be nice to restrict the input to Base32
> >>> characters. Maybe even automatic case correction...
> >>
> >> Actually I think it doesn't help much. Show me a person who can write
> >> base32 encoded string.... But I agree that a validator with some regex
> >> to limit the chars and a note that it should be base32 string is better.
> >> The question is what's the purpose of this field from user perspective.
> >> Is a human being suppose to fill it or is it meant to be only filled by
> >> some provisioning systems? In UI it's just as a backup?
> >>
> >> If there is a use case where user is suppose to choose the key, it would
> >> be better to fill the key and convert it to base32 string on a server.
> >
> > I can't think of any case where a user would use the key field.
> >
> > However, there are at least two important cases where an admin would do
> > this:
> > 1. Hardware tokens
> > 2. Transferring OATH (TOTP/HOTP) tokens from another system
> >
> > Nathaniel
> >
> What is the input format for these two cases? Is it base32 so admin can 
> enter it into UI or is it plain text so he has to use different tool to 
> encode it to base32 and then fill into UI?

In both of the above cases, I suspect the predominant use will be
scripts written to take a token store and import the tokens. This is
mostly a non-UI case.

RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide use.
This is largely because, with fewer characters and no case-sensitivity,
Base32 is easier to type. I don't know of any other encodings in wide
use.

It would be nice to support both of them, but I'm not sure how this is
possible. Suggestions are welcome.

Nathaniel