What causes "invalid y coordinate: %w" in OpenNHP/opennhp?

Encode 'y' with base64.RawURLEncoding on the client, matching 'x'.

invalid y coordinate

Error message

invalid y coordinate: %w

What it means

Identical check for the 'y' coordinate: it must decode as unpadded base64url, otherwise VerifyJWT returns 'invalid y coordinate: %w'. x may decode fine while y fails if the two were encoded by different code paths.

Solutions

Encode 'y' with base64.RawURLEncoding on the client, matching 'x'.
Normalize: trim whitespace and convert '+'/'/' to '-'/'_', remove '=' padding.
Read the wrapped base64 error to identify padding vs character issues.
Audit client code for a second encoding path used for y.
Regenerate the token with a maintained library.

Example fix

// before
yB64 := base64.URLEncoding.EncodeToString(yBytes) // adds padding
// after
yB64 := base64.RawURLEncoding.EncodeToString(yBytes)

Defensive patterns

Strategy: validation

Validate before calling

func coordsDecode(jwk map[string]any) bool {
	x, _ := jwk["x"].(string); y, _ := jwk["y"].(string)
	_, xe := base64.RawURLEncoding.DecodeString(x)
	_, ye := base64.RawURLEncoding.DecodeString(y)
	return xe == nil && ye == nil
}

Try / catch

token, err := VerifyJWT(rawToken)
if err != nil && strings.Contains(err.Error(), "invalid y coordinate") {
	// fix client encoding of y; return 401
}

Prevention

Encode x and y with the same encoder in one helper.
Trim all whitespace before encoding.
Audit re-encoding intermediaries for added padding.
Round-trip test coordinates in client unit tests.
Regenerate tokens with a maintained library when unsure.

When it happens

Trigger: jwk.y is padded base64, contains illegal base64url characters, or includes whitespace. Reached after x decoded successfully during GetResource token verification.

Common situations: Mixed encoders in client code (x fixed, y still using StdEncoding); external tool re-encoding the header with padding; manual token assembly pasting coordinates from a padded-base64 output.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

AI-assisted analysis of OpenNHP/opennhp@6e04ca5ff0 (2026-09-07). Data as JSON: /api/errors/ebee92a91010b11c. Report an issue: GitHub.

Appendix: source

Thrown at endpoints/server/kbs/resource/resource.go:241

	}

	// Convert JWK back to ECDSA public key
	xStr, ok := jwkHeader["x"].(string)
	if !ok {
		return nil, fmt.Errorf("missing x coordinate in jwk")
	}
	yStr, ok := jwkHeader["y"].(string)
	if !ok {
		return nil, fmt.Errorf("missing y coordinate in jwk")
	}

	xBytes, err := base64.RawURLEncoding.DecodeString(xStr)
	if err != nil {
		return nil, fmt.Errorf("invalid x coordinate: %w", err)
	}
	yBytes, err := base64.RawURLEncoding.DecodeString(yStr)
	if err != nil {
		return nil, fmt.Errorf("invalid y coordinate: %w", err)
	}

	publicKey := &ecdsa.PublicKey{
		Curve: elliptic.P256(),
		X:     new(big.Int).SetBytes(xBytes),
		Y:     new(big.Int).SetBytes(yBytes),
	}

	// Now verify the token with the extracted public key
	token, err := jwt.Parse(tokenString, func(token *jwt.Token) (any, error) {
		// Check signing method
		if _, ok := token.Method.(*jwt.SigningMethodECDSA); !ok {
			return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
		}
		return publicKey, nil
	})

	if err != nil {

View on GitHub (pinned to 6e04ca5ff0)