Jianfei Hu

I will +1 on the option to provide a option to match with case insenstive, similiar to Envoy's StringMatcher API https://www.envoyproxy.io/docs/envoy/latest/api-v3/type/matcher/v3/string.proto#string-matcher Where you can specify `ignore_case`. but back to this...

@anhdle14 could you take this? Thanks!

looks good. but want to wait till we resolve the dynamic link issue, so that we have less changing factors for a single release.

It's your istio-proxy container not ready, rather than authservice. Probably check your istio deployments, such as istio-proxy container log, istiod is down or not?

Thanks! I have a quick comment: people working or need to try out this project are mostly from Istio/k8s background. So they are familiar with k8s, and we use k8s...

I checked some doc and our settings, seem only authservice repo itself need to have the read/write permission, which is already the case? https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#upgrading-a-workflow-that-accesses-ghcrio  https://github.com/orgs/istio-ecosystem/packages/container/authservice%2Fauthservice/settings

configuration with regex can be complicated. Istio has long discussion around support for regex in authz policy, but does not introduce due to the complexity. Also we'll have to dig...

#140 iteself can be supported with a new knob to deny by default if not match. Right?

Reading the RFC, `private_key_jwt` would require the client to register a public key to the identity provider. The later on token endpoint requests to the IdP then can be authenticated...

@therealmitchconnors @howardjohn @ericvn @istio/wg-test-and-release-maintainers mind taking a look?