Early in the x9.59 process there were a number of blatently erroneous assertions that account-based represented a closed infrastructure while certificate-based repesented an open infrastructure.
Basically, in both account-based and certificate-based infrastructures ... there can be public key owners, relying parties, and certification bodies. An account-based infrastructure tends to provide online certification while a certificate-based infrastructure tends to create stale, static copies of information (kept in accounts by the certification authority) that can be used in offline scenarios. In both account-based and certificate-based operations, you could have the same exact information being certified, the same exact public key owners, the same exact relying parties and the same exact certifying authorities. An account-based and certificate-based operation can be equally closed or open based on the type of information being authenticated and the degree of trust that the certifying bodies have among the population of relying parties. The blatently erroneuous statement about account/certificate operations differing by being closed/opened wasn't the differentiator; the differentiator between account/certificate operations tends to be whether it is an online operation vis-a-vis offline operation. The other scenario, was that some x.509 identitfy certiificate operations fell into the trap of thinking that they could grossly overload certificates with large amounts of identity and privacy information and widely publish and distribute the information all over the world. As it began to dawn on them that this probably wasn't a good thing, there was a significant reduction in the types of information that might be published in a certificate (many financial institutions retreating to a relying-party-only certificate containing a public key and a customer account number). As the types of identity and privacy information that might be globally published became more & more restricted, effectively certificates became more and more of a closed environment. In that sense, the FSTC FAST paradigm actually represents more of an open infrastructure than any of the privacy tainted certificate paradigms, since it is possible for FSTC FAST to provide online response to an "over 21" assertion w/o divulging the birth date, or to provide an online response to "pay $100" assertion w/o divulging the account balance or the person's name or address. The issue regarding account-based vis-a-vis certificate-based is one of online vis-a-vis offline. However, a online infrastructure has some degree additional latitude in validating various kinds of authenticated assertions w/o unnecessarily divulging identity and/or privacy information which would typically be found in a certificate-based implementation. In that sense, given any concern over not wanting wide-spread publication and distribution of large amounts of identity and privacy information, an online certification operation might be considered to be somewhat more open than a certificate based information .... since it could perform more types of (online) validations w/o unnecessarily widely publishing identity and privacy information. The online paradigm tends to also deal with much more dynamic data (like current account balance) which can be of much more value compared to the offline paradigm (like whether or not a person did or didn't have a specific bank account at some time in the past). somewhat related, the IETF AAA working group just published a new RFC 3539 PS Authentication, Authorization and Accounting (AAA) Transport Profile, Aboba B., Wood J., 2003/06/20 (41pp) (.txt=93110) (was draft-ietf-aaa-transport-12.txt) for a complete list of AAA working group RFCs go to http://www.garlic.com/~lynn/rfcietff.htm and select "Term (term->RFC#)" and then scroll down to "Authentication, Authorization, and Accounting" Authentication, Authorization and Accounting see also accounting , authentication , authorization 3539 3127 2989 2977 2906 2905 2904 2903 past discussions of relying-party-only certificates: http://www.garlic.com/~lynn/subpubkey.html#rpo misc. past threads with open/closed & aads/cads: http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die http://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop http://www.garlic.com/~lynn/aepay4.htm#privis privacy issues http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long) http://www.garlic.com/~lynn/aadsm14.htm#16 Payments as an answer to spam http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate http://www.garlic.com/~lynn/2001g.html#55 Using a self-signed certificate on a private network http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm