> >> Actually, I have a question about interoperability here. > >> > >> It's my assumption that a client of this specification needs to > >> implement basically all the options: > >> > >> * encrypted OTP values and values used for key derivation * > >> separate pins and pins that are together * at least 4 pass mode > >> > >> So that the server has flexibility to implement what its OTP > >> token requires. > >> > >> Are people assuming that it is acceptable to implement a client > >> that only implements the facilities needed by one particular OTP > >> token? > > Simon> Yes, and I believe that is unavoidable -- there is no way to > Simon> properly test all features of any implementation without > Simon> having some OTP token that excercises each feature. > > OK. That makes me very uncomfortable. As an individual I'd prefer > that > this draft not be published without a mandatory-to-implement subset. > My assumption was that the client needed to implement everything. > If that's not globally held I think we have much more work to do. > > Please consider this an individual last call comment, not as a comment > as a chair. 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. --Gareth _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf