Re: [hackathon] One Tax API Hackathon proposal

[Benson Muite <[e-mail]>]

Dear Eliot and Eric,

Thanks for your feedback. Just announcing on this list as suggested in 
the Hackathon wiki. Clearly, not everyone on this list will participate 
in every project, but feedback is still appreciated.

One particular use case is taxation of cloud services:

https://itatonline.org/articles_new/a-closer-look-at-taxation-of-cloud-services-internationally/

Some companies which provide services through the cloud and will be 
affected by such taxes and do have employees who participate in IETF. 
They may want to have some say in how they could easily facilitate 
payment of such taxes in many territories without unnecessary 
administrative burden.

KPMG has a set of articles on e-taxes:
https://home.kpmg/us/en/home/insights/2019/06/tnf-digital-economy0.html

A recent example is from Cambodia:
https://home.kpmg/us/en/home/insights/2021/09/tnf-cambodia-vat-ecommerce.html

Within the EU, Peppol ( https://github.com/OpenPEPPOL/ ) is one effort 
to harmonize electronic invoicing, whether this will be adopted 
internationally remains to be seen. The scope is much broader than 
proposed here.

As you indicate, a hackathon should have a clear achievable target. As 
indicated in a previous reply for VAT/Sales tax, 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 to solve are:
double registration - registering in one jurisdiction should enable you 
to sell in others and comply with regulations the relevant jurisdictions 
for many products and services
paperwork reduction - authorized electronic payments and electronic 
identity confirmation can really help here, for example a certain 
jurisdiction has a paperwork reduction act, the main effect of which is 
to indicate how many hours are needed to fill a form, rather than 
milliseconds of allowed time to respond to an electronic request.

Benson

On 9/26/21 11:43 AM, Eliot Lear wrote:
> EKR,
> 
> The issue here is more about likelihood of actually accomplishing 
> anything.  Do YOU have a codebase that worries about taxes? Do you plan 
> to add this sort of code into your base?  I don't and I don't know 
> anyone who does.  Do you know of any code base to add this stuff to?  I 
> don't and I don't know anyone who does.
> 
> If people who DO have such code bases ARE going to show, then the next 
> question is whether anyone who participates in the IETF can reasonably 
> help them.  This isn't a matter of protocol design.  If not, what does 
> the IETF hackathon bring to the table other than... a table (and right 
> now we can't even bring that)?
> 
> But, Benson, EKR's right:  I can't stand in the way of you doing the 
> work here.  I just think it'll be a waste of your time, and possibly 
> drive you in the wrong direction.
> 
> Eliot
> 
> On 25.09.21 18:23, Eric Rescorla wrote:
>>
>> On Sat, Sep 25, 2021 at 2:19 AM Eliot Lear <[e-mail] 
>> <mailto:[e-mail]>> 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.
>>
>>
>> Without taking a position on this proposal, since when do we monitor 
>> what people work on at the hackathon? It's a lot more like a 
>> free-for-all than a BOF and having people work on something at a 
>> hackathon certainly isn't any kind of commitment to take the work on 
>> at the IETF.
>>
>>     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?
>>
>>
>> These seem like reasonable questions, but I don't agree with the 
>> framing that we "need" to understand them. If you don't want to 
>> participate without an answer, don't do so, but that shouldn't stop 
>> others from doing it.
>>
>> -Ekr
>>
>>
>>     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
>>     <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] <mailto:[e-mail]>
>>     > https://www.ietf.org/mailman/listinfo/hackathon
>>     <https://www.ietf.org/mailman/listinfo/hackathon>
>>     > Unsubscribe: mailto:[e-mail]
>>     <mailto:[e-mail]>?subject=unsubscribe
>>     >
>>
>>     _______________________________________________
>>     hackathon mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/hackathon
>>     <https://www.ietf.org/mailman/listinfo/hackathon>
>>     Unsubscribe: mailto:[e-mail]
>>     <mailto:[e-mail]>?subject=unsubscribe
>>