Introduce a separate field for the signature key of player certificates #254
Comments
|
@evan-goode has already done the job to support multiple keys on #229. |
evan-goode
added a commit
to unmojang/authlib-injector
that referenced
this issue
Dec 4, 2024
Allow authentication servers to specify an array of profile property public keys and an array of player certificate public keys, similar to Mojang's https://api.minecraftservices.com/publickeys route. Adds two new fields, `playerCertificateKeys` and `profilePropertyKeys`, to the authlib-injector metadata route at the root of the API. Both are arrays of strings containing public keys in the same format as the `signaturePublickey`. If `signaturePublickey` is specified, it will be counted as both a player certificate key and a profile property key, which is the status quo. With this change, authentication server A can forward a texture payload from authentication server B, and the client could accept a texture signed by either authentication server. This change also allows more flexibility for authentication server operators. Resolves yushijinhun#254.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello.
We're adopting player certificates functionality into Ely.by's authlib-injector integration. But here is a problem: we would like to have separate keys for properties and players' certificates signing. Right now it's impossible and we have to use the same keys. It would be nice to have an additional field in the metadata response to specify the player's certificates signing key.
It would be perfect to introduce new fields
propertiesPublicKeysandplayersCertificatesPublicKeysas arrays to allow server owners to rotate keys by exposing a few keys during the migration period.The text was updated successfully, but these errors were encountered: