- From: ANDREAE Philip <P.Andreae@oberthur.com>
- Date: Wed, 18 Feb 2015 17:44:12 +0000
- To: Anders Rundgren <anders.rundgren.net@gmail.com>, "public-web-security@w3.org" <public-web-security@w3.org>
- CC: Castillo Laurent <Laurent.Castillo@gemalto.com>
When you introduce PIN you introduce another factor that is governed by other standards and security requirements. In EMV the assumption is that if it is a Clear Text PIN verified in the Chip then the thing that has both the Key Pad and the Card Reader are tamper evident. If the Key Pad and the Card Reader are split then the PIN is to be encrypted between the two components of the solution. If the PIN is to be verified by the Issuing Host then the PIN is not entered into a Key Pad it is entered into a PIN Pad (same device deferent standard) that is governed by a different set of PCI managed standards. These require that the device be tamper resistant. We need to be clear about what we are talking about. For me there are four key words "identification" allows you to present a computer sensible index addressing the question who are you. "Authentication" something to attest to your uniqueness. "Verification" a mechanism to prove that you know the secret. Finally a method of presenting What you rights you have "Authorization". ISO 7813 defined mechanisms to address Identification. ISO 7816 & 14443 allowed these identifiers to be stored in a chip and read through a computer interface. EMV created a means of Authentication and offered a mechanism to support Verification and went a step farther and created a method of support offline (at the Point of Sales) authorization. Now we need to take these well understood mechanisms and allow them to be utilized on the Web through a browser turning Card Not Present Transactions into Card or credential present transaction. Philip Andreae Tel: +1 (404) 680 9640 -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com] Sent: Wednesday, February 18, 2015 12:20 PM To: ANDREAE Philip; public-web-security@w3.org Cc: Castillo Laurent Subject: Re: About Web Crypto WG rechartering, next steps and related topics On 2015-02-18 17:51, ANDREAE Philip wrote: > As a consumer and founder of what became EMV, also an Amex, Europay and Visa Product employee and technology guy. Trust is not an assumption people make when they swipe/tap or insert their card through/into/on a Point of Sale device. Often payment cards are read by terminals that have nothing to do with Payments, for example in the Delta Lounge to allow members in. > > Yes EMVCo type approves terminals. Not for security reasons. It is done to assure global interoperability. By that I mean any EMV Card in an EMV terminal should work or at least be told that payment type not accepted here. > > It is true that in some countries there are different rules. Universally trust should not be an assumption and I would love to be able to tap if possible insert my debit card against/into a Mobile Device, PC or tablet and know that the credentials my Bank enabled can be used as a means of authentication (replacing passwords), and, maybe even identification. Rewriting this is practical terms: In your opinion the "Payment Terminal" may very well be supplied by the MERCHANT as ordinary (=untrusted) web code and that users should be able dealing with questions like "'example.com' wants to access token 'YYZ' in slot #4, please provide a PIN". Note that it is the BROWSER (not the application) that asks this, because it has to do that using the method above. Anders > > Philip Andreae > Tel: +1 (404) 680 9640 > > > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com] > Sent: Wednesday, February 18, 2015 9:39 AM > To: GALINDO Virginie; public-web-security@w3.org > Cc: Castillo Laurent; Lu HongQian Karen > Subject: Re: About Web Crypto WG rechartering, next steps and related > topics > > On 2015-02-18 13:41, GALINDO Virginie wrote: > > Hi Virginie, > > If you pay in a shop using your "Carte Bancaire" you put the card in a terminal provided by a certified vendor of trusted payment terminals, right? > > That is, the card is never directly exposed to potentially malicious merchant code. > > Now if you rather go to the Web, you'll find that the entire concept "Trusted Web Code" [1] is missing which makes all efforts merging generic security hardware [2,3] with browsers doomed to fail. > > Sincerely, > Anders Rundgren > > 1] Trusted UI + Trusted Software > 2] GP TEE, SIM, PIV, TPM, etc. > 3] FIDO/U2F is special purpose and limited by SOP so it is outside of this discussion. > > >> Dear all, >> >> (web security chair hat on) >> >> a lots of interesting and very diverse conversation going on here. I just would like to remind the segmentation of topics and ownership in W3C in ordre to help people to send their use cases, contributions and thoughts to the appropriate location : >> >> - Web Crypto next charter >> The charter will include anything related to cryptographic operation. At the moment, the WG targets the maintenance of the specification to include new algorithms (aka new curve familly). The group is currently discussing the gemalto proposal for certificate management, integrating the usage of hardware token for cryptographic operation, with no consensus on that matter. if you are willing to support one of those topic, please speak on the public-webcrypto mailing list [1]. >> >> - FIDO Alliance and authentication service The topic of >> authentication is currenlty owned and discussed by FIDO Alliance. the level of service expected there is about enrollement and authentication opertaions. That technology is backed by a strong strategy by Microsoft and Google. I suggest we let FIDO Alliance decide when they are ready to input to W3C their contribution in terms which are compliant with W3C IP policy. >> >> - Web Payment services >> That topic is discussed in the Web Payment Interest group, whihc is currently gathering use cases. There are no technical requirements, no technical proposal endorsed in the IG as of today. It may happen that the Web Payment IG ends with that kind of consensual requirements. I can only encourage people interested in payment to join the IG or at least monitor their deliverables [2]. >> >> - Any service accessing secure element That topic will not be >> adressed in the Web Crypto next charter, it has been rejected by main browser makers attending that WG. The way to go on the discussion could be either to create a W3C community group, it is very light and easy to manage and join. But there is another possibility : from what I see, GlobalPlatform is willing to host the discussion in ordre to allow all players to design a flexible technical solution, allowing browser to integrate in a flexible way any services using hardware token. GP will soon open a public working group, with an IP policy compliant with W3C one, to discuss that. >> >> Again, that mail is not to prevent you to share here your ideas and comments, but gives you guideline to make sure your are heard in the appropriate group(s). >> >> Regards, >> Virginie >> chair of the Web Security IG >> >> >> [1] https://lists.w3.org/Archives/Public/public-webcrypto/ >> [2] http://www.w3.org/Payments/IG/ >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> -------- > -- >> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. >> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. >> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> -------- > -- >> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. >> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. >> Although all reasonable efforts have been made to keep this >> transmission free from viruses, the sender will not be liable for >> damages caused by a transmitted virus >
Received on Wednesday, 18 February 2015 17:44:47 UTC