I was goin through the documentation of INDY , in the example with alice,faber and thrift , the part where the credentials are validated is mentioned as
Acme got all the requested attributes. Now Acme wants to check the
Validity Proof. To do it Acme first must get every Credential Schema
and corresponding Credential Definition for each identifier presented
in the Proof, the same way that Alice did it. Now Acme has everything
to check Job-Application Proof from Alice.
Where can I find more details on this validation process ? At this moment acme has apply_job_prrof sent by the Alice agent.
Has this apply job proof ,been signed by Alice ?
So Identification information ,the Transcript details , ( the actual
details are fetched from the blockchain by alice and she just adds
it to the payload ) ?
How does the validation actually work ? What stops Alice from
fabricating a wrong payload?
Indy implements the Aries approach to credential verification. See the following Aries RFC standard:
https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof
The Indy anoncreds design is detailed here:
https://github.com/hyperledger/indy-sdk/tree/master/docs/design/002-anoncreds
The step-by-step example is here:
https://github.com/hyperledger/indy-sdk/tree/master/docs/how-tos/negotiate-proof
And the cryptographic details are in Hyperledger Ursa:
https://github.com/hyperledger/ursa-docs/tree/master/specs/anoncreds1
Related
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 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.
I'm in IT support. We have two types of correspondence:
With final users. The usual external communication with them.
With service providers (DBA, etc) Internal communication that can't be seen for the requestors.
For the first one, we use the 'answer to requestor'.
For the service providers, we use a comment and send CC to the service provider. But when they reply, RT considers their reply as correspondence and execute the actions for the 'correspondence' condition.
Then, when i wanna customize the scrips, RT doesn't distinguish between the actions: an email to the user and a replay from the provider (internal CC) are both "on correspondence" for RT, and send them both to the requestor.
I don't realize how to configure RT for send 1 y 2 to different actions.
Have I configurated something wrong? Which must I consider?
Or must I use a custom user scrip?
Thanks a lot!
RT should do what you are expecting, which is send correspondence (replies) to the requestor and send comments only to staff. There are two areas to look at to sort out why this isn't happening:
1) By default, RT's notification scrips use the Cc role to add another requestor. If you want to add a "commenter," you want to use the AdminCc role rather than Cc. This is likely the problem.
2) If that doesn't fix it, make sure you have two email addresses set up, one for correspondence and one for comment, something like support#example.com (correspond address) and support-comment#example.com (comment address). Then make sure you have your /etc/aliases file set up to route correspond with --action correspond and comment with --action comment. An initial example is provided in step 10 in the RT README.
MY AIM : I am creating a Service provider at my local server using opensaml-java latest library from shibboleth.I want a Test IdP.I chose https://fed-lab.org/ . There is no clear procedure for this configuration also
1.I have created Metadata programmatically using opensaml.
I need to check whether my metadata is correct according to its standard schema.How can i check this?
2.I have registered my SP at https://fed-lab.org/ site after logging in.
3.I have downloaded the Identity Provider from https://fed-lab.org/online/identity-provider-metadata/
It has two IDPSSODescriptors.
In that SIngleSignOnServices are
1.https://openidp.feide.no/simplesaml/saml2/idp/SSOService.php and
2.https://fed-lab.org/simplesaml-test/module.php/fedlab/SingleSignOnService.php
I am using HTTP-Redirect binding
I have created the AuthnRequest message first . then did , deflate , base64encoding , URL encoding as per specification of SAML
https://openidp.feide.no/simplesaml/saml2/idp/SSOService.php?SAMLRequest=processedAuthnRequest
I am trying to access this URL , But I am getting nothing Response from the site.
WHere am I wrong ? please Let me help to figure it out.
Can u provide Test IdPs where there is a clear way(documentation) to do the configuration.
There is a very simple Idp at http://stubidp.kentor.se that doesn't require any kind of registration. Just enter your acs url and a subject nameid to send an unsolited Saml2Response.
It won't let you test everything (yet), but it can get you started on receiving a basic message and handling that.