Elliptic Curve Diffie-Hellman Ephemeral Static, as defined in RFC 6090 , and using the Concat KDF, as defined in Section 5.8.1 of NIST.800-56A, where the Digest Method is SHA-256 and all OtherInfo parameters are the empty bit string

This section defines the specifics of agreeing upon a JWE CMK with Elliptic Curve Diffie-Hellman Ephemeral Static, as defined in RFC 6090, and using the Concat KDF, as defined in Section 5.8.1 of NIST.800-56A, where the Digest Method is SHA-256 and all OtherInfo parameters are the empty bit string. The alg header parameter value ECDH-ES is used in this case.
A key of size 160 bits or larger MUST be used for the Elliptic Curve keys used with this algorithm. The output of the Concat KDF MUST be a key of the same length as that used by the enc algorithm.
An epk (ephemeral public key) value MUST only be used for a single key agreement transaction.

Too bad that the man page does not go into detail in what format priv and pub are... Read the source, Luke!
It seems that the priv key D is just the bytes in hex of the private key BigInteger. The public key seems to be something else but this is no problem because in ECC the public key is G*D where G is a curve parameter.
So the two private keys are now defined here in the JUNIT tests. One is for the sender of the JWE the other for the recipient.

The spec says that the senders key pair is ephemeral and the recipient's key pair is static. So code using this code should generate one ephemeral EC key pair. Stuff the private key and the recipients public key into the encrypt function. These key parts are used for the key agreement. See the wikipedia page for a short explanation.
I will implement the "epk" header parameter at a later time. For now I use the X and Y format to transfer the ephemeral public key to the recipient.
Base64 encoding the header yields:

The next step in my interpretation of the spec is to generate the content encryption key using the key derivation function defined in the NIST paper.
The content encryption is done using the method specified in the enc parameter of the header here: A256GCM
For this method I need a 256bit == 32byte key and a 12 byte IV. So the call to the KDF is:

Special thanks to Mike Jones for writing most of the JW* specs text and to John Bradley for being a fountain of knowledge in all things crypto and identity management protocols and formats. Not to forget Nat Sakimura for starting the OpenID Artifact Binding WG which now does all the OpenID Connect work. Especially for mobile devices we need simple, light weight protocols and formats. JW* and especially ECDH-ES are important for mobile.