RCDS provides flexibility by having few wired-in assumptions about the structure of catalog information. No particular data model is assumed, and any party can (subject to permissions) potentially add any kind of assertion. Catalog information stored in an RCDS server is currently assumed to be ``flat'' lists of (attribute, value) pairs. Clients can retrieve portions of the catalog information for a resource by the attribute's full name or by the prefix of a name.
Likewise, RCDS catalog servers know nothing about particular message digest algorithms or signature algorithms. This allows RCDS to work with multiple existing public-key authentication methods, multiple signature formats, and a variety of key certificate formats. Experience with several other protocols (X.400, X.500, MIME) indicates that it is difficult to retro-fit security into a protocol after it is deployed, especially if there are multiple ways in which a protocol element may be represented. RCDS therefore supports cryptographic authentication without specifying any particular algorithm for signing certificates. In particular, it does not specify the representation of a set of assertions before signing. Such representation is bound to the signature algorithm identifier. In general, RCDS catalog servers do not interpret assertions or certificates. They merely serve as repositories at which they can be stored and retrieved.