RE: [kmip] Description of problems around underspecified Credentials, like Username & Password

My preference would be for the 3rd option.  I believe the 
credential types need to be included and there needs to be a specified way to 
handle exchange of the User/Password credential pair.

From:  
[mailto:] 
Sent: 2010-02-18 11:22 AM
To: 

Subject: [kmip] Description of problems 
around underspecified Credentials, like Username & 
Password

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:

  
Remove the Credential object as mandatory-to-support for the KMIP Server 
  
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. 
  
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