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 _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
