OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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  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?

fn:Matt Ball
org:Oracle USA, Inc.;Key Management
adr:;;500 El Dorado Blvd, Bldg 5;Broomfield;CO;80021;U.S.A.
title:Principal Software Engineer

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]