Hi George, JSON-LD still requires c14n. I opened the particular spec and the c14n job with JSON-LD appears quite complex. The structure of the linked data must also be brought into some particular form.
https://json-ld.github.io/normalization/spec/ C10n of plain JSON should be a simpler job. There should also be more and better software support for that. I don't think we can get around JSON c10n, if we want to keep the message content in clear text. Vladimir On 03/09/18 15:27, George Fletcher wrote: > I'm not a big fan of canonicalization for signatures. In the past it > has been brittle, the libraries subject to bugs, and hard for > developers to adopt. That said, if no canonicalization is not a > requirement, have you checked out JSON-LD? It has embedded signature > support. https://json-ld.org/spec/latest/ > > On 9/3/18 6:23 AM, Dave Tonge wrote: >> Hi Phil >> >> Thanks again for the helpful reply. >> I 100% agree with you about the problem of false negatives with RFC3230. >> I am not in favour of the its use and will do my best to highlight >> these issues with those who are proposing its use with the draft >> cavage spec. >> >> I also share your worry about the potential for things to move back >> to a SOAP style of API. >> >> Having a look at the >> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 >> spec it is quite general purpose, whereas I'm in favour of something >> that is explicitly designed for JSON requests and responses. If there >> was confidence in the JSON canonicalisation described in >> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 then >> this seems to enable APIs to stay REStful but with the support for >> self-contained signatures. For many applications I agree that there >> will need to be some repetition of values in the JSON payload that >> are already in the header, e.g. audience, issuer and time. But if >> general purpose HTTP signing is a lost cause, then "Cleartext JSON >> Web Signatures" seem the next best thing. >> >> Dave >> >> >> >> >> >> >> On Sat, 1 Sep 2018 at 01:06, Phil Hunt <phil.h...@oracle.com >> <mailto:phil.h...@oracle.com>> wrote: >> >> Dave, >> >> I’m not sure this is as useful as one might think - from RFC3230… >>> >>> >>> 7 <https://tools.ietf.org/html/rfc3230#section-7> Security >>> Considerations >>> >>> >>> >>> This document specifies a data integrity mechanism that >>> protects HTTP >>> instance data, but not HTTP entity headers, from certain >>> kinds of >>> accidental corruption. It is also useful in detecting at >>> least one >>> spoofing attack [9 >>> <https://tools.ietf.org/html/rfc3230#ref-9>]. However, it is not >>> intended as general >>> protection against malicious tampering with HTTP messages. >>> >>> The HTTP Digest Access Authentication mechanism [5 >>> <https://tools.ietf.org/html/rfc3230#ref-5>] provides some >>> protection against malicious tampering. >> >> For example, if you have a corporate web proxy or ISP that decides >> to help out by doing content compression as an example, all your >> requests will start failing (so-called accidental corruption). We >> learned from XML that consistent canonicalization of the request >> data is important. >> >> IOW…RFC3230 is valid when it works, but what about all the times >> it fails for no apparent reason? (false negatives) >> >> In my humble experience with REST, the HTTP body is only a small >> part of the transaction. The headers, method, and URL parameters >> contain all of the semantics to an application transaction. Sure >> there are some requests that are just built on HTTP POST. But you >> have to be sure, there are no parameters that matter in the >> headers or URL. >> >> The OAuth WG took a big ambitious stab at this (thanks Justin), >> but we weren’t convinced implementations would be stable.. >> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 >> >> I can’t help but worry we are headed back to RPC style SOAP like >> containers based on JSON tokens that can be signed and that >> contain all the semantics and data of a transaction to be signed. >> Now that I said that, I’m going to go wash my mouth out. Ugh. >> >> Phil >> >> >> >>> On Aug 31, 2018, at 3:05 PM, Dave Tonge >>> <dave.to...@momentumft.co.uk >>> <mailto:dave.to...@momentumft.co.uk>> wrote: >>> >>> Thanks for the replies. >>> You're absolutely right Phil and George - apologies I omitted the >>> digest step from the first email. >>> Both the STET and Berlin Group specs require the use of SHA-256 >>> or SHA-512 digest header as per RFC3230 >>> (https://tools.ietf.org/html/rfc3230 >>> >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3230&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=y5Rg_ik_9mvP1Whrv68p0G885X7gRo32oxxeEeA08Ys&e=>) >>> They then use the draft cavage spec to sign a defined set of >>> headers which includes the date and digest headers.. >>> >>> > If you want attestation, better to use SET or plain JWT. >>> >>> The pushback on this has been that to use JWTs for all API >>> request bodies and responses would make the APIs harder to >>> develop against and debug. >>> However I do think it is a better option than having signatures >>> in headers. I like the idea of using content negotiation to allow >>> clients to request either application/json or application/jwt >>> from an API endpoint. >>> >>> I'd be interested if there is any interest in the working group >>> for this draft though: >>> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 >>> >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf..org_html_draft-2Derdtman-2Djose-2Dcleartext-2Djws-2D00&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=0G1ikcDnNzvZqp7w6xlLnfhtq6GZGc0HlswqLcp4OK4&e=>. >>> As Ben mentioned, does the issue of JSON canonicalization make >>> this a non-starter? >>> >>> Thanks >>> >>> Dave >> >> >> >> -- >> Dave Tonge >> CTO >> Moneyhub Enterprise >> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >> BS1 6FL >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial >> Technology Limited which is authorised and regulated by the Financial >> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered >> on the Financial Services Register (FRN 809360) at >> fca.org.uk/register <http://fca.org.uk/register>. Moneyhub Financial >> Technology is registered in England & Wales, company registration >> number 06909772 . >> Moneyhub Financial Technology Limited 2018 © >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this >> email or of any information in it other than by the addressee is >> unauthorised and unlawful. Whilst reasonable efforts are made to >> ensure that any attachments are virus-free, it is the recipient's >> sole responsibility to scan all attachments for viruses. All calls >> and emails to and from this company may be monitored and recorded for >> legitimate purposes relating to this company's business. Any opinions >> expressed in this email (or in any attachments) are those of the >> author and do not necessarily represent the opinions of Moneyhub >> Financial Technology Limited or of any other group company. > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
