[Openid-specs-fapi] FW: #OBEMeeting: ETSI/OBE Signature Format Meeting - Minutes, Slides & Other Documents

Anders Rundgren anders.rundgren.net at gmail.com
Sat May 2 06:51:58 UTC 2020


On 2020-04-20 11:54, Ralph Bragg via Openid-specs-fapi wrote:
> 
> Attached latest minutes from ETSI working group discussing JaDES message signatures. All comments welcome.

Note: I haven't read the full specification, I just to a shot at the sample :)

Initial observation: Using a hash of a certificate rather than a certificate saves bytes at the expense of brittleness since certificates typically are renewed every two years or so. How are updates supposed to be communicated?  If certificates are considered too voluminous, providing a URL to the certificate path seems like a more reasonable solution for open systems.

Now over to something completely different...
I understand that the Open Banking tradition is to send additional information through HTTP headers. IMO, this becomes slightly less cool if this information also needs to be signed.  This is not the case with current OBIE standards, right?

If I were to update OBIE standards, I would consider moving all data to be signed into the HTTP body.  If applied to the ETSI/OBE sample you would get something like the following:

{
+ "recepientUrl": "https://api.testbank.com/v1/payments/sepa-credit-transfers"
+ "requestId": "99391c7e-ad88-49ec-a2ad-99ddcb1f7721",
   "instructedAmount": {"currency": "EUR", "amount": "123.50"},
   "debtorAccount": {"iban": "DE40100100103307118608"},
   "creditorName": "Merchant123",
   "creditorAccount": {"iban": "DE02100100109307118603"},
   "remittanceInformationUnstructured": "Ref Number Merchant",
+ "psuIpAddress": "192.168.8.78",
+ "psuGeoLocation": "GEO:52.506931,13.144558",
+ "psuUserAgent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0",
+ "timeStamp": "2020-03-04T16:38:37Z",
+ "requestSignature": "eyJiNjQiOiJmYWxzZSYifQ..MNnQk2xmc3XqWqeAQ4UOrgmurA"
}

Moving the signature into the body adds another feature, the entire request can be serialized as a single JSON object.  Yes, it does introduce the need for some kind of JSON canonicalization mechanism. However, canonicalization is also required for signed HTTP headers in the ETSI/OBE proposal so we are already there.  For good or for worse :)

If reviving the "canonicalization monster" actually is an option, I would consider going a bit further down that [slippery?] road:

{
+ "@context": "https://openbanking.eu/std",
+ "@qualifier": "SepaPayment",

    as above

& "requestSignature": {
     "alg": "RS256",
     "x5u": "https://the-trusted-ttp.com/openbanking/certpath",
     "val": "OyltWriKjFuc2QLty_FvgEutNZcRHhNPDC1YaG59Hyt2tWQ"
   }
}

1. The initial @ params were added to make the request a "strictly typed object".
2. Using JSON canonicalization the need for Base64Url-encoded headers disappears.
3. A full cert path permits sub-CA updates without affecting relying parties.  Ideally certificate path URLs SHOULD be updated for each certificate generation to enable future signature validations.

Thanx,
Anders


More information about the Openid-specs-fapi mailing list