>> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf