Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

@rickstaa Thanks so much for opening an issue! I'll triage this for the team to take a look 👀

And welcome to the community! 🎉

While this is awaiting review, help wanted section if you are looking for other ways to contribute. ✨

@rickstaa Also, if this is blocking you, please reach out to our awesome support team for additional help.

And thanks again for the issue and for so clearly defining your problem 💖

• ✔️ id-token: none (works).

@cmwilson21, thanks for your quick response. Take your time; it's not blocking since people can set token-id to none as a workaround 👍🏻.

FWIW, I had the same question today. I'm assuming the write value was chosen because it allows requesting a token which can be used to authenticate to other services (and possibly call arbitrary protected methods), but there doesn't seem to be a clear place that explains what this permission is.

Thanks for opening an issue! We've triaged this issue for technical review by a subject matter expert 👀

there is also a reference to seeing id-token to read under this heading: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token (as value for "Maximum access for
pull requests from public forked repositories")

This is a gentle bump for the docs team that this issue is waiting for technical review.

This is still incredibly confusing.

Super confusing;)

@rickstaa To quote from another thread:

Thank you again for your patience while our Actions SME team reviewed. They wanted to ensure you had a chance to view this portion of the documentation regarding permissioning, and wanted to offer some additional context -

For reusable workflows outside the org and also for pull requests from public forked repos , default value issued to id-token is "read" to be safe and restrictive. Users could change it to "write" if they want to explicitly grant permissions for the workflow to request an OIDC JWT.

Does this help clarify some of the confusion regarding id-token: read/write/none?

Originally posted by @nguyenalex836 in #32320 (comment)

So for me that means, that the id-token can in some scenarios be "read" by default, but can't be explicitly set to that value by the action author(?).

(But with completely basic docs on what the id-token values really mean missing, I can't really make the mental model of what "read" and "to be safe and restrictive" really means in the context, how that differs from "none", probably without seeing some internals of how that is being used in the runners I won't be able to wrap my head around how that works and unfortunately just keep cargo-culting their use as directed by the actions' authors;)…)