On 2017-12-14 05:08, Nat Sakimura wrote:
Part of the reason for people preferring non-base64ed content is the
tooling issue. The current OpenAPI tooling does not take care of the
Base64url encoded body or JWS.
Dear Nat,
I have no inside information on this, I only took a "Snapshot" of the current
situation which nowadays also includes the W3C who in an early writeup are toying with
non-base64ed signatures while still claiming to use JWS:
https://github.com/w3c/webpayments-methods-tokenization/wiki/Generalisation-of-Encrypted-Card#example-1
As it appeared in the W3C document above, 2017-12-14:
{
supportedMethods: "https://example.com/bobpay";,
data: {
signedData: {
merchantIdentifier: "XXXX",
bobPaySpecificField: true
},
unsignedData: {...},
dataSecurity: {
signature: {...},
signatureCertPath: "public.pem"
}
}
}
Doesn't this look like yet another "DIY standard" in progress?
My suggestion is only about "Rounding Out" the suite of already very nice JOSE
standards, by giving implementers a more JSON-centric signature option.
ES6+ compliant JSON serialization fully addresses the once thought "unsolvable"
canonicalization issues.
Best regards,
Anders
Once the support comes, the pain will be much less.
On Fri, Nov 17, 2017 at 3:53 PM Anders Rundgren <[email protected]
<mailto:[email protected]>> wrote:
Dear List,
Here is a list of the three most well-known APIs for Open Banking and their take on
"Signed JSON":
http://openid.net/specs/openid-financial-api-part-2.html#request
In-line JWS (base64url-encoded messages)
https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf#page=56
HTTP-Signatures
<https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf#page=56HTTP-Signatures>
(clear text messages using a not yet standardized signature scheme)
https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-1-0/#usage-examples-merchant-illustrative-interactions-payment-setup
Detached JWS (clear text messages signed by a JWS in a specific HTTP header)
I believe this supports my view that base64-encoded JSON will continue to
be a hard sell no matter how good it may be.
Other "uncool" side-effects include lookup services providing signed
responses in base64url
https://tools.ietf.org/html/draft-ietf-oauth-discovery-07#section-2.1
and security protocols needing artificial outer layers in order to make
objects recognizable
https://tools.ietf.org/html/draft-pei-opentrustprotocol-01#section-8.2.1.1
May I propose a JOSE2 effort based on ES6.JSON serialization [1] to end the current
proliferation of "DIY standards" and reducing the need for [ugly] workarounds
like used by UK's Open Banking?
Making JOSE more Browser/JS friendly wouldn't be a terrible idea, either.
Availability of ES6.JSON compatible tools isn't really a showstopper, we are
talking about < 2000 lines of pretty simple [2] code for parsing and
serialization.
thanx,
Anders
1]
https://cyberphone.github.io/doc/security/jcs.html#Normalization_and_Signature_Validation
2] Well, number serialization is non-trivial so implementers probably need
to build on already written code and algorithms out there like I did.
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
