I am new to EMV development. My question is regarding Tag 91 (Issuer Authetication Data) which is sent by Issuer in EMV response. In my case, when tag 91 is missing in response packet then chip card decides to decline the transaction even if issuer has approved transaction online. So I am wondering whether Tag 91 is a mandatory tag which needs to be sent by issuer each time it approves a transaction online and what is industry wide understanding about it. Please let me know thoughts on it.
Also, In my case, Application Interchange Profile Byte 1, Bit 3 = 1 which means external authentication is required.
Are you working for Card Application or Terminal Application ?
Issuer authentication always have to be performed unless you are doing a partial chip implementation. I am sure you know that it is an additional level of security that ensures that the response came from the correct issuer.
When AIP B1B3 is on, it means card will expect tag 91.
In some cases it is even default. eg. D-PAS( Diners/Discover) AIP B1B3 is off, since it does not support External Authenticate. It is verified during second Gen AC. In such cases if the issuer wants card to not decline the transaction when ARPC not present, in the ACO( Application configuration Option), it is explicitly mentioned about partial chip implementation.
Check each payment scheme card and terminal specifications manual careful before you implement, as any loop holes in implementation may help a fraudster skip the security you wish to provide.Thumb rule, if you get ARPC from issuer, always sent it to card. Let the card decide.
From Card Application side I can add that "Application Interchange Profile Byte 1, Bit 3 = 1 means external authentication is supported, but not required. What does it mean ? Card may support Issuer Authentication, but may not required it for online transaction (issuer authentication can be mandatory or optional in card internal parameters). I.e. for optional it would be great to do auth, but if not - no problem, do online. And if Issuer have not sent tag 91 card may aprove transaction.
Related
The User-Agent Reduction origin trial is valid from Chrome version 95 to 101 according to the official documentation, but looking at the token acquisition screen, it seems to be valid up to version 111. I am currently on version 109. Is this one excluded?
https://developer.chrome.com/en/blog/user-agent-reduction-origin-trial/
https://developer.chrome.com/origintrials/#/view_trial/-7123568710593282047
Also, this one is intended to test in a situation where the user agent string and javascript api have been completely removed or changed. Is there another way to test before they are completely removed?
We would appreciate it if you could enlighten us.
I have added the necessary settings to the response headers, referring to the official documentation, but it does not work correctly.
https://developer.chrome.com/en/blog/user-agent-reduction-origin-trial/
I have looked everywhere for an example of a QSealC signed message, and I could not find any info.
I need to verify the signature of a QsealC signed payload AND I need to sign the responding payload but I understand that the payload is all in json,
Are there examples out there of QSealC signed payloads?
thanks
You will do both the signing and validation as detailed by IETF's draft-cavage-http-signatures, where you should pay special attention to section 4.1.1 for constructing and section 2.5 for verifying the Signature header.
This draft is referenced by both Berlin Group's XS2A NextGenPSD2 Framework Implementation Guidelines and Stet (France). However, note that it's normal that each unique implementation imposes additional requirements on the HTTP Message Signing standard, e.g. by requiring specific headers to be signed or using a specially formatted keyId. I am not sure whether other standardizations such as Open Banking (UK) reference it.
Take note that you do not need actual QsealC PSD2 certificates to begin your implementation work of the neither the signing nor validation process, as you can create your own self-issued certificates, e.g. using OpenSSL, by adding the OID's found in the ASN.1 profile described in ETSI TS 119 495.
However, I strongly recommend you find a QTSP in your region and order certificates both for development and testing, and for use in production when the time comes.
I won't go into details on the actual process of creating the signature itself, as it's very well detailed in draft-cavage-http-signatures, but consider the following example;
You're requesting GET https://api.bank.eu/v1/accounts, and after processing your outgoing request you end up with the following signing string;
date: Sun, 12 May 2019 17:03:04 GMT
x-request-id: 69df69c1-76d0-4590-8f28-50449a21d0d8
psu-id: 289da2e6-5a01-430d-8075-8f7af71f6d2b
tpp-redirect-uri: https://httpbin.org/get
The resulting Signature could look something like this;
keyId=\"SN=D9EA5432EA92D254,CA=CN=Buypass Class 3 CA 3,O=Buypass AS-983163327,C=NO\",
algorithm=\"rsa-sha256\",
headers=\"date x-request-id psu-id tpp-redirect-uri\",
signature=\"base64(rsa-sha256(signing_string))\"
The above signature adheres to Berlin Group requirements as detailed in Section 12.2 in their implementation guidelines (per. v1.3), except some linebreaks added for readability, which in short are ;
the keyId must be formatted as SN={serial},CA={issuer}, but note that it seems to be up to the ASPSP to decide how the serial and issuer is formatted. However, most are likely to require the serial to be in uppercase hexadecimal representation and issuer formatting in conformance with RFC 2253 or RFC 4514.
The algorithm used must be either rsa-sha256 or rsa-sha512
The following headers must be part of the signing string if present in the request; date, digest, x-request-id, psu-id, psu-corporate-id, tpp-redirect-uri
The signature must be base-64 encoded
As developers have just begun to adopt this way of signing messages, you'll likely have you implement this yourself - but it's not too difficult if you just carefully read the above mentioned draft.
However, vendors have begun supporting the scheme, e.g. Apache CXF currently supports both signing and validation from v3.3.0 in their cxf-rt-rs-security-http-signature module as mentioned in the Apache CXF 3.3 Migration Guide. Surely, others will follow.
Validating the actual signature is easy enough, but validating the actual QsealC PSD2 certificate is a bit more cumbersome, but you'll likely have to integrate with EU's List of Trusted Lists to retrieve root- and intermediate certificates used to issued these certificates, and form a chain of trust together with e.g. Java's cacerts and Microsoft Trusted Root Certificate Program. I personally have good experiences using difi-certvalidator (Java) for the actual validation process, as it proved very easy to extend to our needs, but there are surely many other good tools and libraries out there.
You'll also need to pay special attention the certificate's organizationIdentifier (OID: 2.5.4.97) and qcStatements (OID: 1.3.6.1.5.5.7.1.3). You should check the certificate's organizationIdentifier against the Preta directory, as there might be instances where a TPP's authorization is revoked by it's NCA, but a CRL revocation hasn't yet been published by it's QTSP.
DISCLAIMER: When it comes to the whole QsealC PSD2 certificate signing and validation process, I find both Berlin Group and EBA to be very diffuse, leaving several aspects open to interpretation.
This is a rough explanation, but hopefully it give you enough to get started.
I would like to get sample Issuer Script Template 1(Tag 71) or Issuer Script Template 2(Tag 72) value for testing the Kernel Application.
Thanks for the help....
In order that not just anyone pass some issuer script to a card and change its counters, SMI Secure messaging for Integrity( to make sure the data is not altered) and SMC - Secure messaging for confidentiality (to make sure none other can read) is used. Read EMV Book 2 Section 9
Secure Messaging for this.
Once you are done with this part, you can check Book 3 on what script you need to pass to the card.
This is packed in a Template 71 or 72 for the below reason.
Issuer scripts with tag '71' shall be processed prior to issuing the
final GENERATE AC command.
Issuer scripts with tag '72' shall be processed after issuing the
final GENERATE AC command.
Since this involves a MAC( based on your SMI Session Key) and a Cryptogram( based on SMC Session Key), I don't think a sample would help.
I am working on MasterCard Acquisition project using emv Module 6.2. I can successfully generate 1st Ac and retrieve tags from it properly but i am asked to include also the result of the 2nd AC in my ICC data before transmission to the issuer.
How can i generate the 2nd AC and include it in my field 55?
There looks to be some misunderstanding in what you need. can you explain the complete context. Below is how you deal in ideal environment.
In first generate AC
if you get ARQC you send it online to issuer.
If you receive TC you approve the transaction offline.
If it is AAC you decline offline.
Now assume you get ARQC and you are not able to go online, you check default action codes and if allowed you request for TC in second generate. If you get TC your transaction is approved offline, else you get AAC and transaction is declined!!!
---------------------05-Dec-2016-----------------------
Ok then i guess this is what you are looking for. CVR Byte 1 Bit 8 will tell whether second generate AC was requested or not. In an online transaction(after 1st Gen AC) this will be 1.Can you check what is it that you are sending now ?. Check the image for more information.
Now you may not need action codes but fyi, you have three types of action codes. denial (to decline the transaction offline), online( to send transactions to issuer), default( to decide on how to proceed when online was opted but unable to. There are two sets of action codes - Terminal( which is used in terminal action analysis) and issuer( which is used by card action analysis). download emv books here to read more.
Btw, are you doing M-TIP ?
I have an orchestration that receives an XML with some email properties(like: to, from, cc, subject, etc..).
Then I want to send the emailmessage with a dynamic port (and I assigned some of the values according the input xml). After the email has been sent, I want to do some further processing but that processing may only execute when the mail has been delivered succesfully on the SMTP server.
In the functional design they want to have a retry per hour and maximum of one day, after that periode a message must be in the EventLog when it cannot be delivered successfully.
Therefore I set the dynamic port with the context properties BTS.RetryCount to 23 and BTS.RetryInterval to 60.
I have set the dynamic SMTP port delivery notification to "Transmitted" and I have a catch exception block to catch the DeliveryFailureException.
Is this enough ?
It is a litte bit confusing for me reading several blogs if I should mark the scope Synchronized...
Patrick,
You're right, the documentation on this aspect of BizTalk delivery notification is scarce and confusing. After extensive testing, I have not been able to identify a difference wether the Scope is set to Synchronized = true; or not.
The official documentation for the Synchronized setting only applies to shared variables when used in both branches of a Parallel execution.
As for the Delivery Notification itself, I'm currently facing a problem in production where the FILE adapter produces its ACK event before the entire contents of the file is written to the output folder - it renders this part of the solutiong useless!