In the EMV protocol the IMK(ac) is used to generate the session key, which is used to generate an ARQC. The IMK(ac) is exclusive to the chip and the card issuer host
As far as I understand, the card issuers do not share those keys with the card brand (i.e. Visa cannot validate your ARQC, only "The Bank of Peoria" who issued the card can).
When an EMV Apple Pay transaction occurs in which the phone generates the ARQC, which IMK(ac) key is it using? Presumably it can't be the IMK(ac) from the original card, and thus the card issuer cannot validate the ARQC.
If it's an Apple IMK(ac) being used, then does this mean that it is Apple validating that ARQC?
If this is the case, what's the transaction flow that gives Apple the opportunity to validate the ARQC?
[Edited for clarity]
Mobile wallets like Apple/Google Pay don't use the card's PAN, so they don't need to provide the same ARQC that the card would have generated.
Instead, they use network tokens which are then mapped back to the PAN by the scheme.
Before the transaction
the Token Requestor (e.g. Apple) sends its IMKac to the Token Service Provider (e.g. Visa) as part of the onboarding
the Device (i.e. individual phone) is provisioned with a Token that can be mapped back to the PAN by the Token Service Provider as part of adding the card to Apple Pay
During the transaction
the Device:
generates an ARQC, which it includes in the transaction
sends its Token in the place that the PAN would go
the Token Requestor:
swaps out the Token for the PAN, which the issuer can recognise
validates the ARQC using the Token Requestor's IMKac, and forwards the result of this validation to the issuer
Encryption will always use Session keys derived from an IMKac for Cryptogram generation. However the IMK need not be the same as what your physical card uses( you can manage this using a different CVN as host).
The same key will be available with the payment schemes(Visa, MasterCard etc.) who will validate the cryptogram during the transaction and send you the results of verification.
Wallet CVNs are different. If you as a card issuer host wants to verify the cryptogram, then you should have the IMKac for the CVN and your HSM should support the CVN. Ideally you can rely on the verification results code (in 44 for Visa and 48 SE71 for MC) to decide whether it can be approved or no.
In case if you have more documentations from Apple you can share, I would love to go through those :-) .
Related
I have created service to offer the brands to create appointment passes and send via email, brands can create passes and send notification using my service.
This service allows them to send push notifications and using their brand name Can someone suggest as per attached image it’s in conflict or not
.
This clause authorizes your customers to send you their certificates for your service to manage on their behalf. This is a good thing and what you want them to do.
If I read between the lines, I believe you are asking if your service can your own single certificate to send to multiple brands. Attachment 5 to the Developer Agreement states:
You may use the Pass Type ID only for purposes of digitally signing
Your Pass for use with Wallet and/or for purposes of using the APN
service with Your Pass. You may distribute Your Pass Type ID as
incorporated into Your Pass in accordance with Section 2 below only so
long as such distribution is under Your own trademark or brand. To the
extent that You reference a third party’s trademark or brand within
Your Pass (e.g., a store coupon for a particular good), You represent
and warrant that You have any necessary rights. You agree not to
share, provide or transfer Your Pass Type ID to any third party
(except for a Service Provider and only to the limited extent
permitted herein), nor use Your Pass Type ID to sign a third party's
pass.
This strongly suggests you should only use your certificate for passes bearing your own trademark or brand.
It's a grey area. Only you can really decide whether or not you want to risk having your certificate revoked.
Can Widevine DRM client player maintain a log of the keys that have been used for content decryption? The logs could be useful to derive certain statistics, such as to identify till where the content was viewed.
Also, are the keys that are received in 'pssh' data blogs also encrypted with certain token or session key?
pssh contains only KIDs (key ids) or in general protection headers, not the real decryption keys. The application needs to use those KIDs / protection headers to request the license from the license server. The license contains decryption keys but those are never exposed to your application. Keys in the license are encrypted. The only information you have are KIDs.
Widevine client should have some kind of map showing which status of known KIDs and event to notify you when the map changes. For example:
EME: keyStatuses and onkeystatuseschange on MediaKeySession
Android: queryKeyStatus and OnKeyStatusChangeListener in Media DRM
You can use those to monitor usage of keys in your app.
I assume by Widevine DRM you mean Widevine CDM.
Once key is expired (duration of key as per license policy), it is replaced by renewed keys corresponding to KIDs (KeyIDs). So "no" it does not maintain a log of used keys
Pssh box does not have Keys.
It has KeyIds and Init Data from which license request can be prepared by CDM, using which application can fetch license from license Server
For a normal charge transaction to a card through the API either the billing address or shipping address plus the email address needs to be provided to ensure that the transaction is covered under the Chargeback Protection rules. However when charging a customer's card on-file the billing address is already on-file with the card information. So can the billing address be omitted in the transaction request and still have the transaction covered under chargeback protection? or does the billing address for the card on file still need to be provided each transaction? Seems redundant if it is already on file. But don't want to lose chargeback protection by omitting.
You should submit the billing address with the charge request. You are right that it is "on file" with the card, but they are used in slightly different ways, so you should include that information with each charge you create. Ideally you'd store that with the customer record so it would be easy to pull out every time you charge.
When I initiate a transaction from my android app using the register API, it first goes through the oauth flow, then if the merchant allows the permissions(I used default permissions) it opens up the register app's transaction page (where merchant can charge a specific amount of money sent by my android app using credit card). But the merchant cannot see any other options other then credit card processing. How do I enable cash payment, Split Card payment methods?
tenderTypes.add(ChargeRequest.TenderType.CASH);
Take a look at this page in the documentation:
https://docs.connect.squareup.com/api/register/android/
And don't forget about the sample apps here: https://github.com/square/register-android-sdk
edit:
tl;dr: you can't.
You have to create a payment method in order to verify it. Creating a sale does NOT invoke verification, even if verification is enabled globally.
original:
I'm reading about credit card verification, which apparently isn't done automatically during Braintree_Transaction::sale(), but I don't see any options to enable verification on calling sale().
Do I really have to implement (at least) two separate API transactions just to verify a credit card?
Ideally I would like to use a single call to ::sale() to perform validation, authorization, and capture.
I have already enabled verification through my control panel, and I'm using test credit card number 4000111111111115 which, is supposed to be declined, but i'm getting successful transactions with it.
Do I have to create a payment method separately in order to perform validation, even if I have global validation enabled?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
To test card verification results, please adjust the amount of your transaction. Because these cards are not linked to real accounts, Braintree cannot make the small authorization charges that are made in production, and instead the API must rely on the amount of the test transaction to dictate the expected response.
In a Production environment, Card verification is triggered by the creation of payment methods, not by transactions. To enable verification, either enable it across all payment methods, or add the verifyCard option to your PaymentMethod::Create call. The response to PaymentMethod::Create in either of these cases will contain a creditCardVerification object if the verification fails for any reason, allowing you to stop the transaction before sale is called.