If so, then I believe that we need a federated identity and management infrastructure. The difference is that the third-party PKI enrollment model still doesn't make sense, and organizations will take over their own identity issues, as with SAML and Liberty. Once you do that, adding "publicKey" as just another attribute is no big deal. With any luck, the new year will bring the analogy SOAP::other middleware as SAML::x.509 :)
the one detailed presentation that I've so far seen of a SAML based product .... looked like it had exactly the same message flows description that I sat thru in a Kerberos project audit in the '80s. I asked the guy making the presentation about the similarity to Kerberos message flows and he said something to the effect of ah yes, kerberos.
random kerberos refs: http://www.garlic.com/~lynn/subpubkey.html#kerberos
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
