simple ... we can take the trivial purchase order ... using trivial purchase card example.
I send in order ... with an x9.59 signed transaction that effectively asserts that my bank will transfer x amount of money for the order. the business forwards the x9.59 signed assertion and gets back a statement from the financial institution either supporting the payment claim or not. people are bascially in business to make money. this is the simplest. So we go to less trivial ... case where there needs to be somewhat more complex relationship between the two parties ... possible because there is more complex relationship between orders and payments. We contact and express desire to make a relationship. If I'm the contacteee ... i (digitally) sign some assertions. The receiving party contacts my bank, D&B, and posibly some other credit reference operations. This is the existing business process model ... w/o certificates. However ... extending it to digital signature world ... use the FSTC FAST model as to the signed assertions can be things other than about payments. The financial institutions, D&B, and various credit reference operations that are the "authoritative reference" for the particular information respond either affirmative or negative. This is the X9.59 model for all payments, the FSTC FAST model, the business model as how things operate today. We can even find this business model operating within the existing TTP/CA industry today. In this case the two business entities are the parties applying for the certificate and the certification authority. The business process is by the TTP/CA as in the above description, they contact financial institutions, D&B, and possibly other references .... get back the answer and load it into their TTP/CA account-based database. At this point the TTP/CA creates an offline certificate that effectively represents a stale read/only copy of the data and business transaction process that it has just performed (aka a substitute for what is in their account-based repository). From the business process standpoint, the certificate reprsents a stale, r/o representation/standin of the standard business process performed by the TTP/CA. This stale, r/o, representation/standin credential ... representing the standard everyday business performed by the TTP/CA ... can sortof be used business operations and entities that are unable to perform the standard business process operations themselves (aka the certificate ... effectively is analogous to some of the paper certificates that appear on the wall of business claiming that they have passed various checks and verifications and have paid a fee to some organization). The issue of course ... is the stale, r/o standin certificate (representing the process performed by the TTP/CA) a sufficient substitute for a business operation performing their own real-time business verification. The more complex detail behind this issue ... and has shown up in the X.509 identity, individual certificate work .... can a generalized certificate be issue to an entity that is adequate for all possible places that need to do various checks. I can claim that I sort of know the kind of information that needs to be verified for me .... but I may have no idea what actual verification might be done by a large number of different corporations that i wish to deal with ... and whether they specific verification requirements actually correspond to the verification done for the kind of certificate that i had just purchased. So, it is difficult to come up with a definition of any set of generalized business operations that such a certificate would represent. So we start applying KISS. Lets say that the only thing in such a certificate is a public key. I can create a self-signed document that includes a public key. This is basically the process that I mentioned previous is done by TTP/CAs and is a "registration authority" business process than is effectively shared/identical with AADS operations and TTP/CAs. I can create this self-signed document ... which goes directly to the business entity that i'm wishing to establish a relationship. Along with that, I also sign X9.59/FAST type assertion transactions that basically state that the some TTPs are authorized to confirm/validate certain information to the business entity that i'm establishing a relationship with. The business sends of the signed X9.59/FAST type assertions to the various TTPs (financial institutions, D&B, credit checks, etc) and gets back various confirmation information (this is the digital eequivalent of the existing business processes w/o needing a TTP/CA intermediary). The business entity can check that the signature on the self-signed document validates with the public key contained in the document. They can also validate that the signed assertions sent off in real-time to the various TTPs also validate with the same public key. They then register the public key and the confirmation by the various TTPs that they've contacted in an account record. Future communication doesn't need the registration authority process. In effect, the business entity is performing all of their specifically required processes ... that a TTP/CA is trying to emulate in a more general way. The business entity then creates an account record that is a representation of all of those business activities .... and is sort of the thing that the TTP/CA is trying to replace with their certificate representation. As i stated in the previous posts .... the registration process ... and various kinds of verification operations ... are identical in most businesses today and is something what TTP/CAs have trying to emulate and create a certificate substitute for. A major difference is that the TTP/CA is trying to create a generalized acceptable version of that ... that would repsent some value substitute to other parties. In many cases the TTP/CA are duplicating in their backroom, exactly the same process that goes on in every business backroom. So we now get to some of the contractual relationships. In the case where a business entity is directly contacting their TTPs (using "out-of-band" from a TTP/CA standpoint .... or "standard business as usual" from a business proces standpoint) ... it is possible to establish consideration and the basis for contractual relationship and things like liablity between the two parties (a business entity and the TTP). One of the challenges for the TTP/CA paradigm (in addition to getting acceptance that generalized stale certificate verification of information by the TTP/CA is acceptable to a business compared to them performing the same operations themselves) is that there is no basis for contract between the TTP/CA and the business entities (aka relying party in TTP/CA terminology). I buy the certificate from a TTP/CA and provide consideration. That means that there is basis between me and the TTP/CA for contract and possible liablity. However, in much of the world just because I have a contractual relationship with a TTP/CA ... and then I go on to establish a contractual relationship with a (RP) business entity .... it is somewhat harder to show that because I have a relationship with a TTP/CA and a relationship with a RP ... that there is the basis for a contractual relationship between a RP and a TTP/CA. Now we come to the value proposition. A TTP/CA that is dupliating the standard backroom business process that goes on everyday in every business is trying to sell a certificate that is a codified representation of the fact that they've beformed these standared, everyday business processes. Unfortunately in the TTP/CA model ... they aren't selling these certificates to the RP, they are selling these things to public key owner. In additional to the TTP/CA trying to establish a new business paradigm that violates standard acceptable contractual relationships (as per previous paragraph) they are also trying to revise the payment model of the RP paying the TTP for the verification. As stated in the previous posts, governments have been able to establish that the certification is payed for by the person certificated ... rather than by the RP. This is typically done by setting up a government agency responsible for the certification and legislating that the person being certified pay for the license/certification. Simple B2B KISS/Summary TTP/CAs are duplicating backroom verification operations that go on in standard business operations today TTP/CAs are trying to get people to pay for their own certificates .... with are the representation of these backroom verification operations TTP/CAs having people pay for their own certificates ... violates existing business models (both from contractual standpoint and value transfer standpoint) TTP/CAs the succesful model of people paying for their own certificates .... is where govs. sent up regulations and licensing authorities and mandate it TTP/CAs there is assumption that the backroom operation performed by a TTP/CA and represented by the certificate can substitute for some existing business process/expense TTP/CAs there is assumption that the backroom operation performed by a TTP/CA and represented by the certificate involves operations that won't have to be repeated by the RP previous refs http://www.garlic.com/~lynn/aadsm12.htm#50 Frist Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication the succesful example of a new TTP/CA like operation is the age verification businesses that cater to the internet adult oriented industry (gaming and entertainment). They perform a backroom peration that is almost exactly the same as standard TTP/CAs have done for some kinds of personal certificates. Basically, you register with the TTP by supplying your name, address, and credit card number. The TTP does a one dollar auth(orization) & AVS credit card transaction that is never settled (aka never shows up on your credit card bill). The name and address is checked against the name and address on file for the credit card number and if it matches a positive response is made to the TTP. The TTP creates a account record for you. When you go to an adult oriented site, you can be asked to verify your age ... and select one of the TTP services that you've registered with. The web site then does a real-time check with the TTP. The websites get charged by the transactions by the TTP. These "stand-in" TTPs are relying on the $1 credit card authorization by the "real" TTP (the financial institution) as the basis for their determination that you are an adult or not. Note that this does follow the online TTP model (not the offline TTP/CA model) and has the RP paying for the certification ... not the person being certified. The corresponding thing done for certain kinds of certificates by TTP/CA ... is that you pay for your certificate with a credit card. The TTP/CA does an authorization for the amount including the AVS option with your name and address. When the amount is authorized ... they can infur from the approval that the name and address also matches ... and they can stuff it into the certificate as certified. Note both the age verification TTPs and some of the TTP/CAs are relying on the AVS part of a credit card transaction (and in the case of the the age verification transaction ... it is a $1 auth with no settlement that never shows up on your credit card bill) as their backroom certification activity. general aads subject: http://www.garlic.com/~lynn/index.html#aads some past threads involving "registration authority" subject: http://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron? http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ? http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001d.html#46 anyone have digital certificates sample code http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key? http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key? http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001j.html#11 PKI (Public Key Infrastructure) http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are? http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI http://www.garlic.com/~lynn/aadsm3.htm#kiss4 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#x959 X9.59 Electronic Payment Standard http://www.garlic.com/~lynn/aadsm5.htm#ocrp2 Online Certificate Revocation Protocol http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation Protocol http://www.garlic.com/~lynn/aadsm8.htm#softpki3 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki4 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsmail.htm#complex AADS/CADS complexity issue http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices [EMAIL PROTECTED] at 12/11/2002 12:43 am wrote: Lynn, Less is better. Prove one thesis at a time, not hundred. So please describe step-by step how the ad-hoc B2B scheme would work during the sign-up phase. Using the certificates and TTP PKI the process is as follows 1. A business partner sends a signed signup-request to a prospective partner. The request contains contact information about the business partner. 2. The receving party records the TTP-issued DN (not key) as the PKI identity of the associated company. After possible out-of-band checks, the "account record" is created and secure e-business can begin. The point is that now the party has a strong, static, revocable and renewable link to the other partner. It is a bit harder to see how you realize this static-ness in an AADS-scheme where there are no DNs. I believe you must "simulate" such anyway. Hopefully based on DNS rather than X.500. Actually I think you should write a paper about it instead. Anders
