Last Update: 14:02 17 Jul 1997

# Common Credentials Cache API

## Issues/Questions

- The values for "type" are to be "as defined in the Kerberos V5 protocol". I can't find what those numbers are.

      enum cc_data_type {
      	type_ticket = 0,		// 0 for ticket, second_ticket
      	/* Ted's draft spec says these are to be
      	   "as defined in the Kerberos V5 protocol"
      	   all I can find are typdefs,
      	   can't find an enumerated type or #define
      	*/
      	type_address, /* =  <"as defined in the Kerberos V5 protocol"> */
      	type_authdata, /* = <"as defined in the Kerberos V5 protocol"> */
      	type_encryption, /* = <"as defined in the Kerberos V5 protocol"> */
      	cc_data_type_max }; // for validation

- Should we allow zero length names of Named Caches? I'd vote NO.
- Cache Names
  - What does the name of a cache look like (sgr, sgr@umich.edu, ???)
  - How do other vendors know what cache name to pass to cc_open()/cc_create()?
    - a priori knowledge ... we'd better document [enforce syntax?]
    - call cc_get_cache_names() to get a list of names, but then how to pick from list?
- Storing both V4 & V5 credentials
  - Caller needs to specify version on cc_create() & cc_open() via cc_flags.
  - Caller needs to be able to recover version
    - add new return parm to cc_get_cache_names? (getting ugly)
    - go back to cc_seq_fetch_named_cache() and add (cc_get_version() and/or cc_get_flags())
- Should cache DLL know as little as possible about creds, or as much as possible
  - As little as possible
    - Caller can modify dsect without requiring a NEW cache DLL, just a bag-o-bits
    - No verification of dsects
  - As much as possible
    - DLL can verify the heck out of the dsect, at least in debug mode
    - DLL will have to change every time a ticket format changes and maintain backward compatibility