The person(s) mining would need to provide these fields. They are normally created by the sender of a normal transaction whereby a new private / public key pair and corresponding shared ECDH secret is created. In this case the person(s) who successfully mined a block gets to "send" themselves the block reward. But instead of sending it as RingCT type 0 (more on this below), they'll need to split the coinbase into multiple inputs can adopt RingCT type 1. It is not yet mandatory that coinbase transactions do this, but I believe the next hard fork will make this a requirement.

Also pay attention to the RingCT/type: yes/0 field in the first link you provided. There are three types of RingCT, and a 0 indicates NULL :

Null is used for coinbase transactions. There are no inputs to sign, so no signatures can be provided. If a miner uses this mode (as opposed to tx.version == 1) then the coinbase output can be used as a dummy input in any rct transaction (AFAIK, primarily due to how it is stored in a database).

In your second link you'll notice RingCT/type: yes/1 , with type 1 indicating Simple :

Simple is currently used when a transaction has multiple inputs. There is a LSAG signature for each input. Each LSAG is smaller in size than a tx.version == 1 signature, so there is still some space savings over the original signature method.

Source

This accounts for the missing fields.

This may also be of interest to you: RING CONFIDENTIAL TRANSACTIONS