Hi Laura,
a bit late to the party…
We don’t use Forge Remote in our Marketplace app today, so the opt-in doesn’t affect us directly — but two of the modules on your largest-context list are ours, so here is the field usage you asked for. Everything below is what our Custom UI reads from the context today, i.e. exactly the set that would have to travel if we moved to a remote.
jira:customField / jira:customFieldType (field extension context)
Read today:
- extension.fieldValue
- extension.fieldId
- extension.fieldType
- extension.entryPoint
- extension.fieldName
- extension.configurationId
- extension.issue.id, extension.issue.typeId
- extension.project.id
The last three deserve emphasis. We use issue id, issue type id and project id to resolve which field configuration applies. If those are not in the trusted context, we are not degrading a label — we cannot tell which configuration a field should render with, and a frontend-supplied substitute becomes an authorization-relevant input that has to be re-verified server-side on every call.
Not read by us: extension.fieldContextId. We have it typed and never use it.
core:action
- extension.data.inputs
Top-level context (all our modules, roughly in order of how load-bearing it is for us)
- moduleKey, accountId, localId, siteUrl, license, cloudId, locale, environmentType
- localId is not cosmetic for us: we parse it to derive the app id and environment id in order to build in-product URLs. We know of no other source for those.
- We don’t use timezone.
One piece of feedback from the partner side, which I haven’t seen raised in this thread.
Besides the Marketplace app, we build custom Forge apps for regulated enterprises. In our connectivity guidance for those customers, Forge Remote is ranked as the strongest option precisely because each request carries a signed, Atlassian-issued context — site, user, module — instead of relying on network-level trust. That argument is a large part of how Forge Remote gets past a security review.
The trusted/untrusted distinction is the right change, but it moves that line, and I suspect a lot of partner and customer documentation still describes the old one. When you publish the field list in October, it would help a great deal if it came with an explicit statement of what a remote may and may not base an authorization decision on — not the field list, the principle. We are updating our own customer guidance to “never authorize on context fields; use the token’s identity claims and re-verify everything else server-side”, and it would be much easier to point customers at your wording than at ours.
Best,
Paul