|Subject:||RE: [kmip] Description of problems around underspecified Credentials, like Username & Password|
|From:||Zelechoski, Peter (pzel...@essvote.com)|
|Date:||Feb 18, 2010 11:01:43 am|
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: Matt...@Sun.COM [mailto:Matt...@Sun.COM] Sent: 2010-02-18 11:22 AM To: km...@lists.oasis-open.org Subject: [kmip] Description of problems around underspecified Credentials, like Username & Password
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 126.96.36.199.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?