[Openid-specs-fapi] Fwd: New specs for Hashlink and HTTP Signatures released

[Anders Rundgren]

Hi Ralph & Co,

While we ar waiting for the wonders of ETSI, how about evaluating an alterative which offers some compelling features compared to HTTP Signatures including:
- Fully compliant with RFC 7515
- Serializable "pure JSON" request format
- Support for body-less HTTP requests

Draft: https://tools.ietf.org/html/draft-rundgren-signed-http-requests-00
Prague presentation: https://datatracker.ietf.org/meeting/104/materials/slides-104-hotrfc-3-signed-http-requests-shreq-00.pdf
Playground: https://mobilepki.org/shreq/home

There is a variant for those who believe canonicalization is evil [1] as well:
One page showing the differences: https://cyberphone.github.io/doc/research/shreq--jwsjcs--combo--jwsb64.pdf
Draft: TBD (will write one if requested)
Playground: https://mobilepki.org/shreqb64/home

Cheers,
Anders

1] The core of the JCS algorithm is only about a 1-4 kilobytes executable code...

On 2019-05-05 22:05, Ralph Bragg wrote:
> Hi,
> 
> Please see attached the communication from ETSI regarding choices of standards that have been adopted by the standards bodies specifically highlighting some concerns with HTTP Signature.
> 
> Firstly, ETSI ESI has become aware that some PSD2 API standards communities are considering adoption of the Internet Draft standard for HTTP Signatures (https://tools.ietf.org/html/draft-cavage-http-signatures-10). It should be noted that:
> 
>  1. HTTP Signature has status draft only and has not necessarily undergone full review by cryptographic experts concerning possible vulnerabilities inherent to that format
>  2. It makes no direct provision for preventing certificate substitution attacks and can consequently be vulnerable such attacks (cf. RFC 5035, https://tools.ietf.org/rfcmarkup/5035 - Enhanced Security Services for S/MIME) 
> 
> ETSI ESI has published a set of standards, commonly referred to a CAdES and XAdES for digital signatures applied to binary or XML data formats, which support signing arbitrary content even for signatures detached from the data being protected (reference: EN 319 122 and EN 319 132 respectively) which could be used for PSD2 APIs. Also the ETSI PAdES (EN 319 142) standard can be used for signing PDF documents. These mature standards provide protection against known risks, can be used to assure the evidential value of the signatures over the long term and are the accepted formats for advanced electronic signatures and seals under the eIDAS regulation 910/2014.
> 
> *ETSI is also working on an equivalent standard digital signature format to apply signatures to JSON data structures. This builds on the existing IETF RFC 7515 standard for JSON Web Signatures. *
> 
> Cheers,
> 
> Ralph
> 
> *From: *Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of Anders Rundgren via Openid-specs-fapi <Openid-specs-fapi at lists.openid.net>
> *Reply-To: *Financial API Working Group List <Openid-specs-fapi at lists.openid.net>
> *Date: *Sunday, 5 May 2019 at 20:42
> *To: *Financial API Working Group List <Openid-specs-fapi at lists.openid.net>
> *Cc: *Anders Rundgren <anders.rundgren.net at gmail.com>
> *Subject: *[Openid-specs-fapi] Fwd: New specs for Hashlink and HTTP Signatures released
> 
> F.Y.I
> 
> ---------- Forwarded message ---------
> From:*Manu Sporny* <msporny at digitalbazaar.com <mailto:msporny at digitalbazaar.com>>
> Date: Sun, 5 May 2019, 20:34
> Subject: New specs for Hashlink and HTTP Signatures released
> To: W3C Credentials CG <public-credentials at w3.org <mailto:public-credentials at w3.org>>
> 
> 
> 
> Hi all,
> 
> New specs have been published for Hashlink:
> 
> https://tools.ietf.org/html/draft-sporny-hashlink-03
> 
> ... and for HTTP Signatures:
> 
> https://tools.ietf.org/html/draft-cavage-http-signatures-11
> 
> Some highlights from the most recent specs:
> 
> HTTP Signatures
>   * 25 implementations! (no, that is not a typo)
>   * Used by PSD2, Berlin Group, and STeT (European banking standards)
>   * Used for banking standards in Europe, OCAP-LD, HTTP-based DID Auth
>     Secure Data Hub authz (spec on its way in Summer 2019)
>   * We are putting together a test suite in order to do real interop
>     testing for the 25 existing implementations.
> 
> Hashlink
>   * We failed to specify that arbitrary metadata is possible, this
>     version fixes that.
>   * Added Security Considerations section wrt. DO NOT use MD5/SHA-1, etc.
> 
> These are a few of our building block specs for some of the technologies
> being worked on by the CCG.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>