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

[Stephen Kent <kent@xxxxxxx>]

Lynn,

>.... 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.

As I described in a recent message, there are ways to preserve the account
number ID model and to carry a capability that confers authorization, thus
avoiding the need to check the ACL.  Now, if we worry only about financial
applications where an account record must be touched because we need to
check current balances, etc., your argument may be better, but the IETF has
a broader application concern than the ANSI X9 committee, which does focus
on finance.

Steve