How should the Athenz jwk config be distributed?

[ysknkd]

The AuthZpeClient supports both the "traditional athenz.conf" and the "jwk format of athenz.conf". While the traditional athenz.conf can be obtained using the athenz-conf CLI, there seems to be no CLI available for obtaining the jwk format of athenz.conf.

In light of this, I have two questions:

• How are Athenz users expected to obtain the jwk format of athenz.conf?
• We are considering implementing HttpPublicKeyStore.java to retrieve jwk from ZTS, but we are concerned that this implementation is not currently provided. Is there any reason why either the traditional athenz.conf or the jwk format of athenz.conf must be placed as a file before the application starts?

[ysknkd]

Is it assumed that the jwt format of athenz conf will be distributed by sia? https://github.com/AthenZ/athenz/blob/f9f1240a770df867206aa94311e091d7ac49115b/libs/go/sia/agent/agent.go#L342-L347

[ysknkd]

I understand that sia acquires the information via postInstanceRegisterInformation and postInstanceRefreshInformation.

Would it be feasible to expose the jwkConfig utilized by the two methods mentioned above as an API of ZTS? https://github.com/AthenZ/athenz/blob/f9f1240a770df867206aa94311e091d7ac49115b/servers/zts/src/main/java/com/yahoo/athenz/zts/ZTSImpl.java#L411-L414

Or should this be implemented in sia instead?

[havetisyan]

I'm slowly moving away from athenz.conf since that was a proprietary format and instead I prefer to use the jwk format as defined in rfc7517.

the initial implementation relies on SIA to automatically fetch the conf file and keep it updated periodically. This eliminates the need for the client to worry about how to refresh and whenever it sees an unknown key, all it needs to do is to reload the latest file from disk which should be updated.

So I would strongly recommend if you're implement your own SIA, then make this part of the agent so it automatically gets updated daily. The server logic only returns the data if there are changes so you don't waste network resources by sending the data every time.

As far as separate APIs, we already have /oauth2/keys API which returns the ZTS keys in this format. If you want to get the zms keys, we can extend this api to specify an optional query element to specify the service name (e.g. /oauth2/keys?rfc=true is default and returns ZTS keys but if you specify /oauth2/keys?rfc=true&service=zms then it can return the ZMS keys - this way we don't need yet another API

[ysknkd]

Thank you for your proposal. We will consider how we can implement this in our environment.

By the way, regarding the use of JWS policy, I believe that the verification key for ZMS is not inherently necessary. However, is it correct to understand that the current ZTS provides the ZMS verification key in postInstanceRegisterInformation and postInstanceRefreshInformation for backward compatibility?

Specifically, the PublicKeyStore interface used by ZPE has a method named getZmsKey. While the verification of JWS Policy only requires the ZTS verification key, ensuring the principle of Java interface contracts mandates the implementation of this method. https://github.com/AthenZ/athenz/blob/b68e84687542a639c33e49cd67af23950807ca11/clients/java/zpe/src/main/java/com/yahoo/athenz/zpe/pkey/PublicKeyStore.java#L29-L34

I believe that in the future, the ZMS verification key will become unnecessary for ZPE's PublicKeyStore. Is there any difference in understanding?

[havetisyan]

ZTS does not just cater ZPE use cases. It's possible that you have an application that fetches full domain jws files from ZMS and needs the public keys for verification of the signature. So we provide both ZMS and ZTS public keys for all clients.

So while ZPE will eventually no longer need ZMS public keys (most likely we'll remove it from the 1.12.x release scheduled sometime in Q3), ZTS will continue to provide the ZMS and ZTS keys.