It seems to me that a very similar argument can be made regarding the need (or lack there of) for a national identity card. Organizations that require biometric identity can simply record that information in their own databases. The business most widely cited as needing national ID cards, the airlines, already maintain elaborate customer databases for their frequent flyer programs. Adding biometrics, with mileage points or faster check-in as incentive, would be easy enough. Your frequent flyer application would authorize the airline to compare your identifying data with security databases at other airlines, credit bureaus, the government, etc.
If photo matching software is unable to validate two photos of you from different databases, both would be displayed next time you check in. If the clerk decides they match, that would be recorded. If the discrepancy is major, you would be taken aside and the matter investigated. Over time, the confidence in any individual's record would grow as more use is made of it. There is still the problem of protecting the database from alteration, but that applies to whatever database would be used to issue national ID cards as well. Even if high speed data lines are not available at all gates, reservations are normally made well in advance, so a passenger list with biometrics could be prepared overnight and delivered to each gate in printed form (for photos) or on a CD-RW. Last minute reservations could be handled by slower data links or the maker would simply be subject to a higher level of scrutiny. Passport numbers could be requested at the time of an international reservation and checked with the issuing government well before flight. Government's that don't cooperate would have their citizens subject to additional scrutiny. During times of heightened alert, additional cross checking can be implemented. None of this is particularly hard and all the issues of of forged, revoked, stolen or cursorily examined ID cards go away. So do the issues of abuse where petty officials confiscate your ID card leaving you helpless. Arnold Reinhold At 8:22 AM -0700 12/27/01, [EMAIL PROTECTED] wrote: >it isn't that you move it to a central authority .... you move it to an >authority that typically is already established in association with >authorization ... aka in normal business operation, a business relationship >is established that typically consists of creating an account record that >has various privileges associated with that account/entity. For >authentication purposes a public key can be bound to that account and/or >set of privileges. This goes on in the world today .... and would continue >to regardless of whether x.509 identity certificates were issued or not. >given that businesses have to play the registration function for >authorization & privileges ... aka normal procedure doesn't allow somebody >to walk into a random bank and withdraw funds from a random account ... >regardless of who they are ... aka indentity doesn't magically enable a >person to withdraw funds from an arbritrary account ... ability to withdraw >funds typically is a privilege associated with whether or not some entity >is authorized to perform that function for a specific account. As such, the >financial institution has to register lots of information for the account >... also registering a public key is consistent with the existing business >processes, liability, administrative and management infrastructure. > >In effect, large numbers of business processes already exist for >registration, administration, and management of authentication information >.... and having a certificate in the loop doesn't eliminate those business >processes (whether or not I had a certificate .... there still would have >to be something registered that some attribute of "me" has authorization to >do certain things). Doing business flow and informatioin management >optimization just demonstrates that given existing business infrastructures >for registration, administration and management which also includes >certificates it is usually trivially possible to demonstrate that the >actual certificates are redundant, superfulous and extraneous ... aka >directly registering the public key and providing direct binding between >the authentication process and the authorization process .... eliminating a >possibly huge number of extraneous and unnecessary business entities and >business processes associated with certificate-based operation. > >There doesn't have to be any single central authority in a certificateless >model. There can be all sorts of authorities for all sorts of infomation >.... which could be also hypothesized for a certificate-based certification >and authentication model. However, the certificateless exercise typically >trivially demonstrates that any certificate-based solution duplicates >existing business processes which aren't going to be eliminated. Therefor, >it is then possible to demonstrate business optimization where the >duplicate (certificate) business processes can be eliminated as extraneous, >redundant, and superfulous. > > > ><[EMAIL PROTECTED]> on 12/27/2001 7:16 am wrote: > > >As for the "certificateless" model - all this really does is move the >binding from something you can carry around with you to something that >has to be done by a central authority. It is not clear to me why this is >such a marvellous improvement. Unless you happen to want to own the >central authority, of course, which, unlike certificates and CAs, is far >harder to replicate privately and therefore, presumably, potentially >even more profitable than Verisign's cash cow. > >Cheers, > >Ben. > >-- >http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > >"There is no limit to what a man can do or how far he can go if he >doesn't mind who gets the credit." - Robert Woodruff > > > > > > > >--------------------------------------------------------------------- >The Cryptography Mailing List >Unsubscribe by sending "unsubscribe cryptography" to >[EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]