My understanding at this point is that we will not expose anything behind [SecureContext] in ShadowRealms. I don't think that's entirely clear from the prose in IDL yet; I'm looking into clarifying that at the moment.

I think it's worth adding explicit [Exposed=Window,Worker] to the [SecureContext] members and maybe even asserting that needs to be present for [SecureContext] members when their corresponding class has [Exposed=*]. Seems a tad too magical otherwise.

But maybe we should also take a step back and have a discussion on that as it's not clear to me what principles are behind it. At least to me it seems somewhat reasonable to offer UUIDs. But perhaps we don't want the additional [SecureContext] bookkeeping? I can understand that, especially for a v1.

My understanding at this point is that we will not expose anything behind [SecureContext] in ShadowRealms. I don't think that's entirely clear from the prose in IDL yet; I'm looking into clarifying that at the moment.

I don't know that much about ShadowRealms, but I would intuitively expect [SecureContext] to expose things if the ShadowRealm was created in a secure context. If that's not the intention I personally agree with Anne that it might make sense to make that explicit using [Exposed].

A more general comment: this PR only talks about Shadow Realms but the diff makes the Crypto interface [Exposed=*], which also exposes it (including SubtleCrypto and randomUUID) for Worklets (as discussed in #338), right? That might not be an issue, but if you want to expose it for Shadow Realms only, you might want a more specific [Exposed] attribute. Alternatively, if you want to expose it everywhere, I think it'd be good to make that clear in the PR description etc.

Also, the WebIDL spec says:

[Exposed=*] is to be used with care. It is only appropriate when an API does not expose significant new capabilities. If the API might be restricted or disabled in some environments, it is preferred to list the globals explicitly.

That being said, I'm not sure if there's any significant concern about exposing crypto.getRandomValues everywhere, and the other members are gated behind [SecureContext], so perhaps that already sufficiently addresses the concern. But, it might still seem safer to explicitly list the places where it should be exposed?