My application for HMRC VAT production credentials was approved, so this project can (in theory) be used to submit VAT returns from GnuCash:
https://github.com/cybermaggedon/gnucash-uk-vat I say "in theory", my company is not VAT registered yet, so other than testing with an emulator, and the sandbox, I haven't used this in anger. I enquired about including the credentials in open-source projects - I was informed this is OK, this has happened before but I don't know which projects. Reading the documentation, if there's any fraud/inappropriate use, the credentials are going to get pulled by HMRC. There's not much an open-source project can do to prevent inappropriate use if a malicious person chooses to use the credentials inappropriately. Having said that, (my day job is security engineer) it's not difficult to get credentials such as these out of a proprietary desktop or mobile application in which they're embedded if someone malicious wants to do that. A primary defence against abusing somebody else's VAT account is that VAT users have to elect to trust an application, and can choose not to. A secondary defence is the rotation of client secrets if compromised. > >* Lots of subquestions in that regard: *> >* 1. How does HMRC "approve" a bridge for "production" ? And can the code of *> >* the bridge still *> >* change after approval without re-approval ? *> > > There is an approval process. Anyone can get credentials on the sandbox > API, but the approval process applies to getting production credentials. > I'm part-way through the process so I haven't seen it to the end yet. > There are some questionnaires to fill in, and HMRC verify that the API > usage is correct by looking at logs in the sandbox environment. > > There are two types of application: "In-house" is used for an enterprise > which wants production access to submit their own VAT records. "Retail" is > used for a developer which creates a VAT product for other people to use. > I'm part-way through a retail application. > > The API reference is public online, but you get access to more detailed > documentation by submitting an application for production credentials. > > > >* Is there a check on the resulting binary or do they *> >* use some other kind of validation ? *> >> > No, there is no validation of the binary / code itself. The HTTP request > must meet what HMRC call the 'Fraud API' which is a bunch of headers > describing various things like the hardware, device ID, local IP/MAC > address, software version, etc. The internal use of these headers is not > defined, but I guess there's some anomaly detection for fraud/abuse > purposes. > > > >* 2. Do you intend to keep your bridge as a separate project, to which *> >* gnucash can interface ? *> >* Or would you like the functionality to become part of the gnucash code ? *> >> 3. Will you provide your integration (in whatever form) in a way that it's > >* compatible with the *> >* GPL code (under which gnucash is released) ? *> >> > The code I published at github.com/cybermaggedon/gnucash-uk-vat is a > separate bridge which uses the Python API, and licenced under GPL. I would > be up for getting involved in an development to integrate a capability with > Gnucash if there's enough interest. > > Mark. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
