Re: [hackathon] One Tax API Hackathon proposal

[Benson Muite <[e-mail]>]

Hi,

Thanks for your response. As a relatively open and neutral gathering of 
people with technical expertise, many of whom use and operate parts of 
the internet, this is probably a good setting to produce a technical 
draft that can be operationalized. High level agreements would of course 
be needed, but without some framework produced by people with technical 
expertise, these may take a long time to come into practice. Data models 
are certainly needed.  In many cases, one needs:
i) Relevant tax collection bodies
ii) Identification numbers for the parties involved
iii) Type of good or service and the relevant taxes to be paid, eg. 
sales tax, income tax
iv) Some database lookup on the amount of tax to be paid.

The main problems solve are:
double registration - registering in one jurisdiction should enable you 
to sell in others and comply with regulations the relevant jurisdictions
paperwork reduction -  authorized electronic payments

These would make small and moderate transactions easier to do, which 
regulatory burdens can make unprofitable.  As many payments for such 
services are already done electronically (with relevant methods for 
authentication and collection of payment fees), specifying a method to 
query for the relevant compliance information can build on top of this. 
Traditional financial intermediaries already have identity information 
and comply with local laws.

Tax residency is a complicated issue, see for example 
https://en.wikipedia.org/wiki/Taxation_of_digital_goods
Costs of protecting consumer rights for physical goods, and malware 
prevention for digital goods encourage honesty in digital transactions.

An example of information an enterprise needs to comply with for 
e-commerce in Norway is available at:
https://www.trade.gov/knowledge-product/norway-ecommerce
A benefit of using the internet for commerce is that people in many 
different jurisdictions can reach your website.  Registering to do 
business in every jurisdiction where people can access your website is 
very burdensome.

To limit the scope for a hackathon, would suggest an initial focus on 
sales tax/VAT which usually goes to an official body in the location of 
the consumer or where the consumers payment method is registered.

Benson


On 9/25/21 12:18 PM, Eliot Lear wrote:
> Hi,
> 
> In general I like a low bar for hackathons, but I am not sure that the 
> IETF should take this one on.  For one, it's not clear to me that this 
> isn't more a matter of data models rather than APIs. We also have no 
> experience with handling of this sort of information: this is WAY up the 
> stack.
> 
> But if you're going to do this, we need to understand what code is going 
> to be hacked.  Are the developers from accounting packages going to 
> participate?  Can you lay out a bit more of a landscape here?
> 
> Eliot
> 
> 
> On 25.09.21 11:04, Benson Muite wrote:
>> Hi,
>>
>> Have proposed a hackathon topic on One Tax API:
>> https://trac.ietf.org/trac/ietf/meeting/wiki/112hackathon
>> Many countries are proposing taxes on e-commerce and also labor 
>> services that are supplied from outside their jurisdictions that have 
>> been enabled by improvements in internet connectivity. Complying with 
>> these requirements can be time consuming and is a trade barrier for 
>> trade in items and services that do not require regulatory approval. 
>> Having a standardized API for reporting and paying these 
>> electronically would enable compliance at a low cost, especially since 
>> automation could be used.  Privacy and security considerations are 
>> also important in creating a standard for such an interface. The aim 
>> of this hackathon project is to develop a prototype implementation 
>> that could become an RFC and be adopted as a standard.
>>
>> Suggestions and contributions are welcome.
>>
>> Regards,
>> Benson
>>
>> _______________________________________________
>> hackathon mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hackathon
>> Unsubscribe: mailto:[e-mail]?subject=unsubscribe
>>
>