我到处都看过QSealC签名消息的示例，但找不到任何信息。 我需要验证QsealC签名的有效负载的签名，并且需要对响应的有效负载进行签名，但是我知道该有效负载全部在json中，
是否有QSealC签名的有效负载示例？
谢谢
答案 0 :(得分：1)
您将按照IETF draft-cavage-http-signatures的详细说明进行签名和验证，在这里您应特别注意4.1.1部分的构造和2.5部分的验证{{1} }标头。
Berlin Group XS2A NextGenPSD2 Framework Implementation Guidelines引用了该草稿。我不确定Open Banking（英国）是否会引用其他标准化，但我知道Stet（法国）会引用，尽管他们已经对其提出了自己的要求，例如要求特殊的Signature标头作为其签名字符串的一部分，而Berlin Group则不需要。
请注意，您不需要实际的QsealC PSD2证书即可开始执行签名或验证过程，因为您可以创建自己的自签发证书，例如通过添加在ETSI TS 119 495中所述的ASN.1配置文件中找到的OID，使用OpenSSL。
但是，我强烈建议您在您所在的地区找到QTSP并订购证书以进行开发和测试，以及在时间到时用于生产。
我不会详细介绍创建签名本身的实际过程，因为在draft-cavage-http-signatures中已经非常详细地介绍了签名，但是请考虑以下示例；
您正在请求(request-target)，并且在处理了外发请求之后，您将得到以下签名字符串；
GET https://api.bank.eu/v1/accounts生成的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
可能看起来像这样；
Signature上述签名符合柏林集团在实施准则（第v1.3版）中第12.2节中详细说明的要求，但为便于阅读而添加了一些换行符，简称为;
keyId 的格式必须为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))\"
，但请注意，由ASPSP来决定如何格式化序列号和发行者格式。但是，大多数可能要求序列号必须采用大写十六进制表示形式，并且发行者的格式必须符合RFC 2253或RFC 4514。
使用的算法必须为SN={serial},CA={issuer}或rsa-sha256
如果请求中存在以下标头，则它们必须是签名字符串的一部分； rsa-sha512，date，digest，x-request-id，psu-id，psu-corporate-id
签名必须为base-64编码
由于开发人员刚刚开始采用这种对消息进行签名的方式，您可能会自己实现这一点-但是，只要您仔细阅读上述草案，这并不难。
但是，供应商已开始支持该计划，例如如Apache CXF 3.3 Migration Guide中所述，Apache CXF当前在其tpp-redirect-uri模块中支持从v3.3.0进行签名和验证。当然，其他人也会跟随。
验证实际签名很容易，但是验证实际QsealC PSD2证书比较麻烦，但是您可能必须与EU的List of Trusted Lists集成在一起，以使您的信任库保持同步，然后简单地通过通过一些现成的验证器（例如difi-certvalidator）。
您还需要特别注意证书的cxf-rt-rs-security-http-signature和organizationIdentifier (OID: 2.5.4.97)。您应该对照Preta目录检查证书的organizationIdentifier，因为在某些情况下，TPP的授权被其NCA吊销了，但是其QTSP尚未发布CRL吊销。
免责声明：在整个QsealC PSD2证书签名和验证过程中，我发现Berlin Group和EBA都非常分散，留下了一些可供
解释的地方这是一个粗略的解释，但希望它能给您足够的入门知识。