Which almost never actually happens for any SOOC JPEG.
Basically all cameras I’ve ever seen use some sort of tone curve in addition to the sRGB transfer function, and do NOT indicate that in ICC tags.
A most extreme example would be Sony S-Log picture profiles. Gamut and transfer function are NEVER tagged in an ICC profile. The closest you’ll get is a Picture Profile EXIF tag that just says “this was shot in S-Log2 mode”, leaving it up to the user to make a matching ICC profile and embed it.
I’m 95% certain Fuji doesn’t embed an ICC tag that matches the actual camera behavior either.
We know for certain from the thread on Panasonic V-Log that Panasonic cameras don’t embed an ICC profile that matches the actual gamut and transfer function the camera used.
If the camera does something fairly consistent/predictable that maps well to an ICC profile (gamut transform on linear data followed by per-channel tone curve - which IS common), one can use an approach such as Debevec’s Algorithm to reverse engineer the TRC, followed by a ColorChecker to reverse engineer the gamut. Or if the camera manufacturer posted the actual mathematics transfer functions (S-Log2/3, V-Log, etc) and gamut (S-Gamut/etc), then you can easily make a matching ICC profile.
But the majority of the time you’re going to have a JPEG that has had an unknown S-curve applied to it and can, at best, be assumed to be sRGB transfer function and gamut as an extremely rough approximation without some pretty serious reverse engineering. You definitely can NOT assume the camera tagged the JPEG correctly.
I’m not sure about Canon, but given that people are trying to reverse engineer their picture styles format (which they do apparently embed? see Reverse Engineering Picture Styles ), it’s unlikely they’re embedding an appropriate ICC that actually matches camera behavior.