1) No it's not. Apple is not storing your card on their iTunes Servers.
2) Yes it is. Apple is not storing your card on their iTunes Servers.
1) Apple may not be storing your card on their iTunes server but they most definitely are storing it in their backend system.
2) No, the card data is not being stored on the phone. Apple has already said this.
Apple says on apple.com
Quote from apple.com:
With Apple Pay, instead of using your actual credit and debit card numbers when you add your card, a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element, a dedicated chip in iPhone and Apple Watch. These numbers are never stored on Apple servers. And when you make a purchase, the Device Account Number alongside a transaction-specific dynamic security code is used to process your payment. So your actual credit or debit card numbers are never shared with merchants or transmitted with payment.
Apple says the Device Account Numbers are not stored on Apple servers. Not that the CC info is not stored on Apple servers. It does not say that the actual card info is stored in the "Secure Element". I am not sure how Apple is matching the unique Device Account Number to the CC info, but they probably have a decryption scheme for the Device Account Number. The backend needs the CC info at the point of authorization so somehow they are looking it up. It clearly says this Device Account Number plus a transaction specific security code is used to process the payment, not the CC info. Having the actual card info on device, even in some encrypted form that they would decrypt, would be a security hazard as some day, the "Secure Element" will be hacked. Apple knows this.
That just makes it even more stupid. The merchant isn't talking to Apple to get a token for CC info stored on Apple's servers. For ****'s sake! Apple set this up exactly how I've been stating ever since Touch ID came out.
I never said they did. Please read what I wrote. Not with your biases.
I clearly said that the merchant PASSES THE DEVICE SUPPLIED TOKEN to the backend, which processes it, and passes back the success (which I called a "token" in a generic technical sense, not any sort of device ID token). It is a one way from device, through the merchant POS, to the backend to process.
No, no, no. Apple issues the "token"... This was all explicitly described in their digital transactions patent that was shown here and on Patently Apple a while ago. You need to do the basic research before you post.
I clarified myself later that it was one-way from device to backend, after reading more from Apple. I was speculating (which I admitted to) based on how other token based systems work.
And you make the assumption that this patent reflects how Apple actually does it. Maybe, maybe not.
I clarified myself later that it was one-way from device to backend, after reading more from Apple. I was speculating (which I admitted to) based on how other token based systems work.
And you make the assumption that this patent reflects how Apple actually does it. Maybe, maybe not.
No, no, no. Apple issues the "token"... This was all explicitly described in their digital transactions patent that was shown here and on Patently Apple a while ago. You need to do the basic research before you post.
I don't think I said anything different in terms of Apple issuing the token. I said the processor does, and that Apple may be the "processor." I was talking about general token based systems in any case.
I did not go to the USPTO and read the actual patent. I did glance at the diagram posted here and also speculated based on general token based systems that exist. I have since clarified my remarks based on what Apple has actually said about Apple Pay.
Apple says the Device Account Numbers are not stored on Apple servers. Not that the CC info is not stored on Apple servers. It does not say that the actual card info is stored in the "Secure Element". I am not sure how Apple is matching the unique Device Account Number to the CC info, but they probably have a decryption scheme for the Device Account Number. The backend needs the CC info at the point of authorization so somehow they are looking it up. It clearly says this Device Account Number plus a transaction specific security code is used to process the payment, not the CC info. Having the actual card info on device, even in some encrypted form that they would decrypt, would be a security hazard as some day, the "Secure Element" will be hacked. Apple knows this.
1) Why the **** would apple have you scan in your card just to send it to their servers? They aren't doing that. they also aren't monitoring your purchases.
2) Of course they aren't saving the ACTUAL CC info to the Secure Element, that's why there is a representational value of the CC data stored LOCALLY.
3) You're inclusion of ACTUAL now is smarmy knowing full well I never claimed ACTUAL CC info as listed on the physical card and very clearly stated otherwise. Again, no one has stated that the ACTUAL card info was ever stored on the device. That's you trying your argument when I discredited your comments about Apple being involved in every transaction.
I did not go to the USPTO and read the actual patent. I did glance at the diagram posted here and also speculated based on general token based systems that exist. I have since clarified my remarks based on what Apple has actually said about Apple Pay.
Yes, well, you need to spend the time and actually read through the patent for a fuller picture of how it works. Go directly to the source. As much time as you've wasted posting uninformed nonsense you could've easily read and digested the patent.
You make the assumption that the patent outlines exactly how Apple Pay works. It may or may not.
Apple isn't going to go to the trouble of filing a very long and detailed patent for a system that precisely mimics the apparent functionality of Apple Pay... and then not implement it. You're trolling hard, dude.
[@]chadbag[/@], I jumped in here when you commented on Apple's backend needing to be present for every transaction despite clearly stating they will not know any of your spending habits. (See below)
[QUOTE="chadbag"]The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security.[/QUOTE]
I jumped in here when you told [@]auxio[/@] "NO. I think this is backwards." for saying, "I'm assuming the CC data would be stored locally on the phone in the secure enclave (same as your fingerprint). That way it could work even if there's no network connection available."
He didn't say the CC data would be the ACTUAL card data. In fact, he clearly stated "same as your fingerprint" which is a hash value that cannot be used to recreate your ACTUAL fingerprint. Now a hash value and token are different but for all intents and purposes it's the same same result for the Secure Enclave and Secure Element insofar the ACTUAL print and card data is not ACTUALLY being stored.
I'll tell you what, if ?Pay is not usable when the iPhone 6/6+ neither has a cellular or a WiFi connection I will buy you an ?Watch. If it is, you buy me one.
1) Why the **** would apple have you scan in your card just to send it to their servers? They aren't doing that. they also aren't monitoring your purchases.
2) Of course they aren't saving the ACTUAL CC info to the Secure Element, that's why there is a representational value of the CC data stored LOCALLY.
3) You're inclusion of ACTUAL now is smarmy knowing full well I never claimed ACTUAL CC info as listed on the physical card and very clearly stated otherwise. Again, no one has stated that the ACTUAL card info was ever stored on the device. That's you trying your argument when I discredited your comments about Apple being involved in every transaction.
Quote:
Originally Posted by SolipsismX
1) Why the **** would apple have you scan in your card just to send it to their servers? They aren't doing that. they also aren't monitoring your purchases.
2) Of course they aren't saving the ACTUAL CC info to the Secure Element, that's why there is a representational value of the CC data stored LOCALLY.
3) You're inclusion of ACTUAL now is smarmy knowing full well I never claimed ACTUAL CC info as listed on the physical card and very clearly stated otherwise. Again, no one has stated that the ACTUAL card info was ever stored on the device. That's you trying your argument when I discredited your comments about Apple being involved in every transaction.
#1) Because it is easier and less error prone than having the user type the info in. And they also have proof of physical possession. They specifically say that they take the info and get approval from the issuer based on the scan, so they are uploading it. And I never claimed they are monitoring your purchases. They say they aren't and they have no need to. But they will keep transactional data in an audit trail for compliance and regulatory use, settle dispute use, etc.
#2) You say that now, but throughout the thread yesterday when I talked about storing CC info on the phone, you never ONCE contradicted it. And there is a difference between touchID fingerprints and CC data using your method. They don't have to recreate the fingerprint based on the stored data -- they just have to store enough metrics to uniquely identify through some sort of one way matching algorithm. The CC info they would have to reconstruct because Visa/MC/Amex etc use card numbers as the basis for their processing. And being able to reverse the process somehow is dangerous and where your idea falls apart.
#3) You did claim that and never contradicted me when I said that was your position. Only today (or late yesterday) did you clarify yourself.
#3) You did claim that and never contradicted me when I said that was your position. Only today (or late yesterday) did you clarify yourself.
I clarified myself a year ago.
But here's how I started this conversion. Note, you responded to my first quote stating you didn't understand. Clearly you still don't.
"...except in this case they can't simply read and use the data off your cards."
This next one was you mistaking what Touch ID is and how it would be used if somethng was able to steal your iCloud credential where you believe all these CCs will be stored on Apple's Servers where these tokens will be popped down into the Secure Element when you login with a new iPhone.
"You do realize they use hashes for the prints — even if using the same finger(s) — will be different, right?"
@chadbag, I jumped in here when you commented on Apple's backend needing to be present for every transaction despite clearly stating they will not know any of your spending habits. (See below)
I jumped in here when you told @auxio "NO. I think this is backwards." for saying, "I'm assuming the CC data would be stored locally on the phone in the secure enclave (same as your fingerprint). That way it could work even if there's no network connection available."
He didn't say the CC data would be the ACTUAL card data. In fact, he clearly stated "same as your fingerprint" which is a hash value that cannot be used to recreate your ACTUAL fingerprint. Now a hash value and token are different but for all intents and purposes it's the same same result for the Secure Enclave and Secure Element insofar the ACTUAL print and card data is not ACTUALLY being stored.
I'll tell you what, if ?Pay is not usable when the iPhone 6/6+ neither has a cellular or a WiFi connection I will buy you an ?Watch. If it is, you buy me one.
You still don't have a clue on what I am saying. Still, after all these times.
Their system needing to be available is totally different than them monitoring/tracking/recording your spending habits.
Their system has to be available to authorize the transaction that the merchants POS forwards. If not, who does? How does that work? And how can Apple disable it with "Find my iPhone"?
AS I pointed out, the fingerprint and CC info comparison is a bad comparison because the fingerprint does not need to be recreated to match, but the CC info does, which makes the CC info too dangerous to store in the "Secure Element" because that element will eventually be hacked and the CC info exposed. This is especially true if Apple's servers are not involved, as they would then need to share this decryption routine with others and the more you share it, the less secure it is.
I've never claimed that the system won't work if a cell or WiFi connection is not available. The only connection that has to be available, as I already said, is between the merchant's POS and the processing backend, which will communicate with Apple's backend at some point (whether the merchant's POS goes to Apple's backend, or the merchant's processor backend goes to Apple's backend, I don't know and make no claims about). In order for Apple to be able to disable a transaction from a lost device, their servers need to be involved. At some point. And if they DO have some sort of cool decryption which can recreate the CC info stored in the "Secure Element" they would have to either be involved to provide that decryption service in the backend process at some point or share that decryption routine, which is the key to the kingdom, with a lot of partners, in order to make this work, and that would not be secure.
But here's how I started this conversion. Note, you responded to my first quote stating you didn't understand. Clearly you still don't.
"...except in this case they can't simply read and use the data off your cards."
This next one was you mistaking what Touch ID is and how it would be used if somethng was able to steal your iCloud credential where you believe all these CCs will be stored on Apple's Servers where these tokens will be popped down into the Secure Element when you login with a new iPhone.
"You do realize they use hashes for the prints — even if using the same finger(s) — will be different, right?"
I understand how TouchID works and I know the hashes or encrypted metrics are different even with the same finger. And they cannot recreate your finger from the stored metrics. But they would need to be able to if the actual card data was stored there. And that is the fatal flaw in your idea.
But here's how I started this conversion. Note, you responded to my first quote stating you didn't understand. Clearly you still don't.
"...except in this case they can't simply read and use the data off your cards."
This next one was you mistaking what Touch ID is and how it would be used if somethng was able to steal your iCloud credential where you believe all these CCs will be stored on Apple's Servers where these tokens will be popped down into the Secure Element when you login with a new iPhone.
"You do realize they use hashes for the prints — even if using the same finger(s) — will be different, right?"
I've never said that Apple is storing all this CC data in iCloud. I did say they would have to store it somewhere to make the system work. Whether they will populate your new device with old card data when you change your device will be seen. If you can in some way, they will make it a safe and secure way.
Their system needing to be available is totally different than them monitoring/tracking/recording your spending habits.
So Apple gets the info from the merchant for the sale and then sends them a token if it's allowed and yet you still claim Apple couldn't keep a record of any of this. :no: sigh I give up on you.
But they would need to be able to if the actual card data was stored there. And that is the fatal flaw in your idea.
Again — and for the very last time — you're the only one talking about the ACTUAL card data being stored in the Secure Element. Everyone else is talking about the representational card data (i.e.: token), as noted by [@]auxio[/@]'s very clear post, being stored LOCALLY.
So Apple gets the info from the merchant for the sale and then sends them a token if it's allowed and yet you still claim Apple couldn't keep a record of any of this. :no: sigh I give up on you.
Again — and for the very last time — you're the only one talking about the ACTUAL card data being stored in the Secure Element. Everyone else is talking about the representational card data (i.e.: token), as noted by [@]auxio[/@]'s very clear post, being stored LOCALLY.
You guys are making it more complicated than it has to be. I used to have a SecureID (picture below) token generator that I used whenever I wanted to access company email on a outside computer. The device was programmed with a algorithm, and once it started it generated a password every minute. As long as the device, and end service were synchronized at one point with both using the same algorithm simultaneously the token password word work.
The SecurID token generator is now built into the tablets we were given. We use a password to generate a token, but on a iPhone that can be done using Touch ID.
You guys are making it more complicated than it has to be. I used to have a SecureID (picture below) token generator that I used whenever I wanted to access company email on a outside computer. The device was programmed with a algorithm, and once it started it generated a password every minute. As long as the device, and end service were synchronized at one point with both using the same algorithm simultaneously the token password word work.
[image]
1) Good ol' SecurID. I kind of miss using their 2-factor authentication.
2) That's the assumption. Didn't Cook even say the device generates a one-time use token? Before he stated that I assumed it would be a one-time token per card per device, which is already inherently much safer than a physical card, but it sounded like he meant there is a one-time token per card per device that generates one-time use tokens to send to the payment agent.
So Apple gets the info from the merchant for the sale and then sends them a token if it's allowed and yet you still claim Apple couldn't keep a record of any of this. sigh I give up on you.
Again — and for the very last time — you're the only one talking about the ACTUAL card data being stored in the Secure Element. Everyone else is talking about the representational card data (i.e.: token), as noted by @auxio's very clear post, being stored LOCALLY.
I didn't say (nor did Apple) that they COULDN'T keep a record of any of this. Apple said that they DON'T TRACK what you are buying if I remember the video correctly. I can guarantee that an audit trail is being kept of transactions due to regulatory compliance and the need to follow up on disputes, etc. There is a big difference between tracking what you are buying, and logging transactions.
Apple does not get a list of your items, total, and your card token to process. It gets (in simple terms -- I don't have actual details) some sort of transaction id, total, and card token and processes that AND LOGS IT. That is not tracking what you buy but it is being able to go back and prove you did a certain transaction for a certain amount. There are regulatory compliance needs that need to be satisfied in this system.
I am the one that should give up on you since you can't keep your story straight.
You are talking about the ACTUAL CARD DATA BEING STORED ON THE DEVICE whether representational or not. If there is no Apple lookup of actual card data on the back end, per YOU, in order for the data to be processed, it had to come from somewhere, which you claim is the device. So that "representational data" stored on the device has to be able to be reversed back to the original data, so in effect, that original data IS stored on the device to anyone who has the algorithm/keys etc that need to be used to reverse the process. There is no difference mathematically speaking between the two cases if the processes is reversible, which it would have to be in order for the way you have explained it to work. This CANNOT work exactly the same way the fingerprints do because the fingerprints don't need to be reversible, but the card data would have to be in order to process the transaction.
@SolipsismX Please outline in detail, with numbered lines that can be referred to in asking questions or requesting clarification, or providing critique, exactly in your mind how Apple Pay works with a transaction. Every step please. Using this scenario:
I walk up to the cashier at one of the main street stores at Disney World (as Apple said that Disney has committed to have WDW online by December IIRC), give them my items, and they ring it up and conveniently tell me that the total comes up to $100.00. I present my iPhone 6 at the contactless payment system terminal (I assume they will use the same one they use with their own wireless wristband system you can use to charge against your WDW resort or hotel room which is pretty slick). Now, using that scenario, please outline step by step what happens in your mind, using the system you envision for Apple Pay (or ?Pay if you prefer). We need every step in the process until the cashier and my phone get the approved signal.
Comments
1) No it's not. Apple is not storing your card on their iTunes Servers.
2) Yes it is. Apple is not storing your card on their iTunes Servers.
1) Apple may not be storing your card on their iTunes server but they most definitely are storing it in their backend system.
2) No, the card data is not being stored on the phone. Apple has already said this.
Apple says on apple.com
Apple says the Device Account Numbers are not stored on Apple servers. Not that the CC info is not stored on Apple servers. It does not say that the actual card info is stored in the "Secure Element". I am not sure how Apple is matching the unique Device Account Number to the CC info, but they probably have a decryption scheme for the Device Account Number. The backend needs the CC info at the point of authorization so somehow they are looking it up. It clearly says this Device Account Number plus a transaction specific security code is used to process the payment, not the CC info. Having the actual card info on device, even in some encrypted form that they would decrypt, would be a security hazard as some day, the "Secure Element" will be hacked. Apple knows this.
That just makes it even more stupid. The merchant isn't talking to Apple to get a token for CC info stored on Apple's servers. For ****'s sake! Apple set this up exactly how I've been stating ever since Touch ID came out.
I never said they did. Please read what I wrote. Not with your biases.
I clearly said that the merchant PASSES THE DEVICE SUPPLIED TOKEN to the backend, which processes it, and passes back the success (which I called a "token" in a generic technical sense, not any sort of device ID token). It is a one way from device, through the merchant POS, to the backend to process.
No, no, no. Apple issues the "token"... This was all explicitly described in their digital transactions patent that was shown here and on Patently Apple a while ago. You need to do the basic research before you post.
I clarified myself later that it was one-way from device to backend, after reading more from Apple. I was speculating (which I admitted to) based on how other token based systems work.
And you make the assumption that this patent reflects how Apple actually does it. Maybe, maybe not.
I clarified myself later that it was one-way from device to backend, after reading more from Apple. I was speculating (which I admitted to) based on how other token based systems work.
And you make the assumption that this patent reflects how Apple actually does it. Maybe, maybe not.
Did you read the patent? I'm guessing you didn't.
No, no, no. Apple issues the "token"... This was all explicitly described in their digital transactions patent that was shown here and on Patently Apple a while ago. You need to do the basic research before you post.
I don't think I said anything different in terms of Apple issuing the token. I said the processor does, and that Apple may be the "processor." I was talking about general token based systems in any case.
Did you read the patent? I'm guessing you didn't.
I did not go to the USPTO and read the actual patent. I did glance at the diagram posted here and also speculated based on general token based systems that exist. I have since clarified my remarks based on what Apple has actually said about Apple Pay.
1) Why the **** would apple have you scan in your card just to send it to their servers? They aren't doing that. they also aren't monitoring your purchases.
2) Of course they aren't saving the ACTUAL CC info to the Secure Element, that's why there is a representational value of the CC data stored LOCALLY.
3) You're inclusion of ACTUAL now is smarmy knowing full well I never claimed ACTUAL CC info as listed on the physical card and very clearly stated otherwise. Again, no one has stated that the ACTUAL card info was ever stored on the device. That's you trying your argument when I discredited your comments about Apple being involved in every transaction.
I did not go to the USPTO and read the actual patent. I did glance at the diagram posted here and also speculated based on general token based systems that exist. I have since clarified my remarks based on what Apple has actually said about Apple Pay.
Yes, well, you need to spend the time and actually read through the patent for a fuller picture of how it works. Go directly to the source. As much time as you've wasted posting uninformed nonsense you could've easily read and digested the patent.
Yes, well, you need to spend the time and actually read through the patent for a fuller picture of how it works. Go directly to the source.
You make the assumption that the patent outlines exactly how Apple Pay works. It may or may not.
You make the assumption that the patent outlines exactly how Apple Pay works. It may or may not.
Apple isn't going to go to the trouble of filing a very long and detailed patent for a system that precisely mimics the apparent functionality of Apple Pay... and then not implement it. You're trolling hard, dude.
[QUOTE="chadbag"]The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security.[/QUOTE]
I jumped in here when you told [@]auxio[/@] "NO. I think this is backwards." for saying, "I'm assuming the CC data would be stored locally on the phone in the secure enclave (same as your fingerprint). That way it could work even if there's no network connection available."
He didn't say the CC data would be the ACTUAL card data. In fact, he clearly stated "same as your fingerprint" which is a hash value that cannot be used to recreate your ACTUAL fingerprint. Now a hash value and token are different but for all intents and purposes it's the same same result for the Secure Enclave and Secure Element insofar the ACTUAL print and card data is not ACTUALLY being stored.
I'll tell you what, if ?Pay is not usable when the iPhone 6/6+ neither has a cellular or a WiFi connection I will buy you an ?Watch. If it is, you buy me one.
1) Why the **** would apple have you scan in your card just to send it to their servers? They aren't doing that. they also aren't monitoring your purchases.
2) Of course they aren't saving the ACTUAL CC info to the Secure Element, that's why there is a representational value of the CC data stored LOCALLY.
3) You're inclusion of ACTUAL now is smarmy knowing full well I never claimed ACTUAL CC info as listed on the physical card and very clearly stated otherwise. Again, no one has stated that the ACTUAL card info was ever stored on the device. That's you trying your argument when I discredited your comments about Apple being involved in every transaction.
1) Why the **** would apple have you scan in your card just to send it to their servers? They aren't doing that. they also aren't monitoring your purchases.
2) Of course they aren't saving the ACTUAL CC info to the Secure Element, that's why there is a representational value of the CC data stored LOCALLY.
3) You're inclusion of ACTUAL now is smarmy knowing full well I never claimed ACTUAL CC info as listed on the physical card and very clearly stated otherwise. Again, no one has stated that the ACTUAL card info was ever stored on the device. That's you trying your argument when I discredited your comments about Apple being involved in every transaction.
#1) Because it is easier and less error prone than having the user type the info in. And they also have proof of physical possession. They specifically say that they take the info and get approval from the issuer based on the scan, so they are uploading it. And I never claimed they are monitoring your purchases. They say they aren't and they have no need to. But they will keep transactional data in an audit trail for compliance and regulatory use, settle dispute use, etc.
#2) You say that now, but throughout the thread yesterday when I talked about storing CC info on the phone, you never ONCE contradicted it. And there is a difference between touchID fingerprints and CC data using your method. They don't have to recreate the fingerprint based on the stored data -- they just have to store enough metrics to uniquely identify through some sort of one way matching algorithm. The CC info they would have to reconstruct because Visa/MC/Amex etc use card numbers as the basis for their processing. And being able to reverse the process somehow is dangerous and where your idea falls apart.
#3) You did claim that and never contradicted me when I said that was your position. Only today (or late yesterday) did you clarify yourself.
I clarified myself a year ago.
But here's how I started this conversion. Note, you responded to my first quote stating you didn't understand. Clearly you still don't.
"...except in this case they can't simply read and use the data off your cards."
This next one was you mistaking what Touch ID is and how it would be used if somethng was able to steal your iCloud credential where you believe all these CCs will be stored on Apple's Servers where these tokens will be popped down into the Secure Element when you login with a new iPhone.
"You do realize they use hashes for the prints — even if using the same finger(s) — will be different, right?"
@chadbag, I jumped in here when you commented on Apple's backend needing to be present for every transaction despite clearly stating they will not know any of your spending habits. (See below)
I jumped in here when you told @auxio "NO. I think this is backwards." for saying, "I'm assuming the CC data would be stored locally on the phone in the secure enclave (same as your fingerprint). That way it could work even if there's no network connection available."
He didn't say the CC data would be the ACTUAL card data. In fact, he clearly stated "same as your fingerprint" which is a hash value that cannot be used to recreate your ACTUAL fingerprint. Now a hash value and token are different but for all intents and purposes it's the same same result for the Secure Enclave and Secure Element insofar the ACTUAL print and card data is not ACTUALLY being stored.
I'll tell you what, if ?Pay is not usable when the iPhone 6/6+ neither has a cellular or a WiFi connection I will buy you an ?Watch. If it is, you buy me one.
You still don't have a clue on what I am saying. Still, after all these times.
Their system needing to be available is totally different than them monitoring/tracking/recording your spending habits.
Their system has to be available to authorize the transaction that the merchants POS forwards. If not, who does? How does that work? And how can Apple disable it with "Find my iPhone"?
AS I pointed out, the fingerprint and CC info comparison is a bad comparison because the fingerprint does not need to be recreated to match, but the CC info does, which makes the CC info too dangerous to store in the "Secure Element" because that element will eventually be hacked and the CC info exposed. This is especially true if Apple's servers are not involved, as they would then need to share this decryption routine with others and the more you share it, the less secure it is.
I've never claimed that the system won't work if a cell or WiFi connection is not available. The only connection that has to be available, as I already said, is between the merchant's POS and the processing backend, which will communicate with Apple's backend at some point (whether the merchant's POS goes to Apple's backend, or the merchant's processor backend goes to Apple's backend, I don't know and make no claims about). In order for Apple to be able to disable a transaction from a lost device, their servers need to be involved. At some point. And if they DO have some sort of cool decryption which can recreate the CC info stored in the "Secure Element" they would have to either be involved to provide that decryption service in the backend process at some point or share that decryption routine, which is the key to the kingdom, with a lot of partners, in order to make this work, and that would not be secure.
I clarified myself a year ago.
But here's how I started this conversion. Note, you responded to my first quote stating you didn't understand. Clearly you still don't.
"...except in this case they can't simply read and use the data off your cards."
This next one was you mistaking what Touch ID is and how it would be used if somethng was able to steal your iCloud credential where you believe all these CCs will be stored on Apple's Servers where these tokens will be popped down into the Secure Element when you login with a new iPhone.
"You do realize they use hashes for the prints — even if using the same finger(s) — will be different, right?"
I understand how TouchID works and I know the hashes or encrypted metrics are different even with the same finger. And they cannot recreate your finger from the stored metrics. But they would need to be able to if the actual card data was stored there. And that is the fatal flaw in your idea.
I clarified myself a year ago.
But here's how I started this conversion. Note, you responded to my first quote stating you didn't understand. Clearly you still don't.
"...except in this case they can't simply read and use the data off your cards."
This next one was you mistaking what Touch ID is and how it would be used if somethng was able to steal your iCloud credential where you believe all these CCs will be stored on Apple's Servers where these tokens will be popped down into the Secure Element when you login with a new iPhone.
"You do realize they use hashes for the prints — even if using the same finger(s) — will be different, right?"
I've never said that Apple is storing all this CC data in iCloud. I did say they would have to store it somewhere to make the system work. Whether they will populate your new device with old card data when you change your device will be seen. If you can in some way, they will make it a safe and secure way.
So Apple gets the info from the merchant for the sale and then sends them a token if it's allowed and yet you still claim Apple couldn't keep a record of any of this. :no: sigh I give up on you.
Again — and for the very last time — you're the only one talking about the ACTUAL card data being stored in the Secure Element. Everyone else is talking about the representational card data (i.e.: token), as noted by [@]auxio[/@]'s very clear post, being stored LOCALLY.
You guys are making it more complicated than it has to be. I used to have a SecureID (picture below) token generator that I used whenever I wanted to access company email on a outside computer. The device was programmed with a algorithm, and once it started it generated a password every minute. As long as the device, and end service were synchronized at one point with both using the same algorithm simultaneously the token password word work.
Here's some reading for a better understanding.
http://en.m.wikipedia.org/wiki/SecurID
The SecurID token generator is now built into the tablets we were given. We use a password to generate a token, but on a iPhone that can be done using Touch ID.
2) That's the assumption. Didn't Cook even say the device generates a one-time use token? Before he stated that I assumed it would be a one-time token per card per device, which is already inherently much safer than a physical card, but it sounded like he meant there is a one-time token per card per device that generates one-time use tokens to send to the payment agent.
So Apple gets the info from the merchant for the sale and then sends them a token if it's allowed and yet you still claim Apple couldn't keep a record of any of this.
Again — and for the very last time — you're the only one talking about the ACTUAL card data being stored in the Secure Element. Everyone else is talking about the representational card data (i.e.: token), as noted by @auxio's very clear post, being stored LOCALLY.
I didn't say (nor did Apple) that they COULDN'T keep a record of any of this. Apple said that they DON'T TRACK what you are buying if I remember the video correctly. I can guarantee that an audit trail is being kept of transactions due to regulatory compliance and the need to follow up on disputes, etc. There is a big difference between tracking what you are buying, and logging transactions.
Apple does not get a list of your items, total, and your card token to process. It gets (in simple terms -- I don't have actual details) some sort of transaction id, total, and card token and processes that AND LOGS IT. That is not tracking what you buy but it is being able to go back and prove you did a certain transaction for a certain amount. There are regulatory compliance needs that need to be satisfied in this system.
I am the one that should give up on you since you can't keep your story straight.
You are talking about the ACTUAL CARD DATA BEING STORED ON THE DEVICE whether representational or not. If there is no Apple lookup of actual card data on the back end, per YOU, in order for the data to be processed, it had to come from somewhere, which you claim is the device. So that "representational data" stored on the device has to be able to be reversed back to the original data, so in effect, that original data IS stored on the device to anyone who has the algorithm/keys etc that need to be used to reverse the process. There is no difference mathematically speaking between the two cases if the processes is reversible, which it would have to be in order for the way you have explained it to work. This CANNOT work exactly the same way the fingerprints do because the fingerprints don't need to be reversible, but the card data would have to be in order to process the transaction.
@SolipsismX Please outline in detail, with numbered lines that can be referred to in asking questions or requesting clarification, or providing critique, exactly in your mind how Apple Pay works with a transaction. Every step please. Using this scenario:
I walk up to the cashier at one of the main street stores at Disney World (as Apple said that Disney has committed to have WDW online by December IIRC), give them my items, and they ring it up and conveniently tell me that the total comes up to $100.00. I present my iPhone 6 at the contactless payment system terminal (I assume they will use the same one they use with their own wireless wristband system you can use to charge against your WDW resort or hotel room which is pretty slick). Now, using that scenario, please outline step by step what happens in your mind, using the system you envision for Apple Pay (or ?Pay if you prefer). We need every step in the process until the cashier and my phone get the approved signal.