Description of problems around underspecified Credentials,like Username & Password

[Matt Ball <Matthew.Ball@Sun.COM>]

Hi Folks,

To expand on today's discussion around the lack-of-specification for any Credentials Types, I'm hoping to better explain the problem (future interoperability issues) and suggest some ways around the problem.

In kmip-spec-1.0-cd-06, there is the requirement to support the Credential Type (see 12.1, item 1b), and an underspecification of the Credential Type Enumeration (see 9.1.3.2.1).  This leads to problems in testing server conformance of the Credential Type, and can encourage vendors to create ad-hoc formats for the various credential types listed in the enumeration field.  Note that kmip-usecases-1.0-cd-07 (the latest use-cases document) shows an example of using the "Username & Password" Credential with the value "CredentialA:secret", implying that the official format for passing Usernames and Passwords is to concatenate the two fields with a colon (":") in between.

To avoid the problems around ad-hoc formats for the Credential Values, the group should consider taking one of the following actions:

1. Remove the Credential object as mandatory-to-support for the KMIP Server
2. Remove the four unspecified enumerations from Table 195 "Credential Type Enumeration" (specifically, remove 'Username & Password', 'Token', 'Biometric Measurement', and 'Certificate' -- leaving only 'Extensions'), and update the usecases document to show the client sending a vendor-specific Credential Type, and the Server rejecting the credential as unsupported.
3. Specify a format for the 'Username & Password' Credential and include this format in the use-cases document.  One example would be to concatenate the username and password with a colon.  Of course, the drawback with this approach is that it prevents usernames from containing a colon.  Another possibility would be to include a length field for the username.  Yet  another possibility would be to make a separate enum for the Username and Password, and allow passing multiple Credential structures.

Based on discussion in today's meeting, I'm guessing that the group will favor the second choice (where all four Credential enumerations are removed), since this carries the least amount of work.  However, the third choice would provide more meaningful support for interoperability.

Thoughts or comments?

Thanks!
-Matt

begin:vcard
fn:Matt Ball
n:Ball;Matthew
org:Oracle USA, Inc.;Key Management
adr:;;500 El Dorado Blvd, Bldg 5;Broomfield;CO;80021;U.S.A.
email;internet:matthew.ball@sun.com
title:Principal Software Engineer
tel;work:303-272-7580
tel;fax:303-272-3023
tel;cell:303-717-2717
x-mozilla-html:TRUE
url:http://www.oracle.com
version:2.1
end:vcard