Could those same engaged Committers answer:
* Does this provide an optional enhancement that can be ignored by
implementations that don't want it?
* If optional, is there a way to enforce it across a domain of APIs? i.e.
require it.
* Given that this creates a security model or enhances the finerac
I encourage the 3 committers engaged on this email thread to review and
merge that PR related to this if they stand behind it. I cannot.
On Sun, 26 Jul 2020, 21:12 Avik Ganguly, wrote:
> Hi everyone,
>
> Thank you for showing interest in discussing this bit of infrastructure.
>
> My opinion is
Hi everyone,
Thank you for showing interest in discussing this bit of infrastructure.
My opinion is that it's valuable for black box pen testing and passing
audits. Note that most auditors (especially outside the PCI space) don't
have a fixed set of rules, guidelines or best practices. Even if th
>From reading a description of the issue in 1034 (have not looked into the
PR), an example where this functionality could eventually help (and is
distinct from our usage of HTTPS) would be in scenarios involving PCI
compliance in server to server communications.
Assume Org A offers Fineract on a
Hi All,
Is there anyone here with experience on how this PR can help Fineract?
https://github.com/apache/fineract/pull/1032
This might be valuable work but I don't understand the use case and
am reaching out to you all to see if someone can help.
I tried to review it but could not understand it
