Perhaps something like

diff --git a/data/org.freedesktop.portal.RemoteDesktop.xml b/data/org.freedesktop.portal.RemoteDesktop.xml
index 0a93ea4..6bc2ca6 100644
--- a/data/org.freedesktop.portal.RemoteDesktop.xml
+++ b/data/org.freedesktop.portal.RemoteDesktop.xml
@@ -134,6 +134,15 @@
               more information about the @handle.
             </para></listitem>
           </varlistentry>
+          <varlistentry>
+            <term>hint s</term>
+            <listitem><para>
+              A localized user facing string meant to provide a hint
+              about the context the application intends use the shared
+              resources. Portal backends may incorporate this into potential
+              dialogs allowing users to make more well informed decisions.
+            </para></listitem>
+          </varlistentry>
         </variablelist>
 
         The following results get returned via the

But would perhaps be good to also provide some more guidelines. For example avoid "Hint" in the text, or "Allow them to access following resources?" since those can be stylized better by the backend.

Anyhow, I think this makes sense to have.

I'd have chosen description for the name, but I agree it makes sense to have this

I'd have chosen description for the name, but I agree it makes sense to have this

Works for me.

Weighing in here with some design input. I agree that description or purpose is a better term here over "hint". As for how this could be displayed to the user, this could simply be a part of the existing portal dialog wherein the reason for the request is presented as part of the overall request, see the quick mockup below for an example.

+1. I would also like such option be available for the ScreenCast portal? The use-case I have here is web browsers, where we can show the user specific web page that is asking to share a screen.

I would also like such option be available for the ScreenCast portal?

I see no reason to limit it to the remote desktop portal. The remote desktop and screen cast portals come hand in hand after all.

see the quick mockup below for an example.

We still need to have some kind of separation, one where the portal provides trusted info about the source, and then a way for the application to provide context/description, e.g.

Select monitor to share with Some App

╭────────────────────────────────────╮
│ www.videomeeting.com is requesting │
│ to access your screen              │
╰────────────────────────────────────╯

In the first part, we only know about the application ID, not about any user or context inside that application, at most we can say what application and e.g. provide an application icon.

The second part would be completely provided by the application. I think the thing we need to define is what expectations applications can have on how it will be presented, so that it is possible to know how to formulate the text in a way that fits into how it is presented.

FWIW, I don't think that the reason for requesting screencast access should be in shown in the portal authorisation dialogue, it should be in the application instead, except for debugging purposes. See the "Displaying a Custom Screen Before a Permission Alert" section for an example:
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/accessing-user-data/

Ideally, just like when popping up a file chooser, the reason for asking access is clear based on context.

The authorisation workflow for websites is obviously different, especially when the browser doesn't trust the site, and the site doesn't trust the portal, so this might will need careful design.

Maybe the reason for authorisation is only displayed when the program statically declares itself as being a browser because in all other cases the application should be showing details ahead of time?

@hadess on OBS Studio, multiple screencasts can be set up simultaneously, and even with the screencast restoration feature, multiple dialogs can pop up (e.g. when monitors changed or previously shared windows are not available anymore). Hinting which scene and source on the dialog is the only good option I can think of. What would you suggest on this case?

on OBS Studio, multiple screencasts can be set up simultaneously, and even with the screencast restoration feature, multiple dialogs can pop up (e.g. when monitors changed or previously shared windows are not available anymore). Hinting which scene and source on the dialog is the only good option I can think of. What would you suggest on this case?

It would be good to know what's going on this case a bit better. Is a single screen share request for OBS equivalent to a website requesting access to the screen? Generally speaking, these user requests are about privacy - you're agreeing to show a particular recipient your screen, whether that be a website or an app. The idea in each case is that there's a different viewer on the other side.

The other thing to consider here is how we handle multiple simultaneous requests, because multiple dialogs popping up at the same time doesn't sound like a great experience...

Three points from a UX design perspective:

1. Showing an URL as a descriptor is pretty straightforward. It doesn't need to be translated, and would be fairly easy to incorporate into a authorization dialog. "Firefox wants to share your screen with meet.gnome.org" works fine.

2. I'm not sure what non-URL descriptors of share destinations would look like in practice. "OBS wants to share your screen with "my show episode 2"" doesn't quite make sense. (On the other hand, "OBS wants to view your screen" does work.)

3. I have some concerns about including a longer explanation from an app. I suspect that these would often state the obvious, be low quality, and not fit with the rest of a permission dialog. Plus there's the translation issue.

For web browser URLs, if it is certain that the web browser will forward the record to said website, then it is fine. If not, it's not right. The portal should tell the truth. Even if we communicate in a portal dialog that the given reason comes from the app, does this have any real added value since the given reason could probably be false? in other words, would it be worth presenting a potentially false reason to the user? In my opinion, no.