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.
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