On Fri, 2011-08-19 at 08:53 -0400, [email protected] wrote: > I had always thought the same way as Sam, that clients would be > required to implement all of the options since there appears to be no > other way for them to support different disconnected token types. The > specification was intended to be token independent and the assumption > was always that the clients would also be.
I agree, at least at the general level and for disconnected tokens. (Does nextOTP make any sense for disconnected tokens?) As for testing: you can unit-test client code using faked-up KDC responses without a real token of the given type. With only unit tests there's always a risk that you will verify the wrong thing (i.e. not the behavior you need to get a new token type working), but I think that risk is acceptable in this case. _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
