RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

[Lynn.Wheeler@xxxxxxxxxxxxx]

.... there are actually well-studied scenerios where if merchants
&/or merchant representatives turn on certain flags claiming that
they have done various authentication processes ... they pay
less money .... and they turn on the flag on all transactions
regardless of whether they performed the authentication function.

that is also one of the scenerios that contribute to merchant fraud

substitute the word relationship for trust ... and talk about relationship
propogation/representation and relationship context. for simple minded
relationship/trust contexts that are relatively static ... letter's of
introduction, certificates, etc ... can attest to the relationship/trust on each
transaction w/o having to resort to any additional information

trust/relationships that have a more complex context in the business world tends
to resort to account records to represent real-time and/or information
aggregation regarding the relationship/trust.

in a relying-party-only certificate ... there is no propogation and/or external
representation of that relationship/trust-factor. it typically reflects the
account number. if the transaction is signed and the account number has to be
hit in any case ... then a certificate is redundant and superfulous for those
transactions. The account record represents the complex relationship/trust
context that is needed to span multiple transactions.