first draft for an intent-handover spec

[ylebre]

This PR is a first draft for an intent-handover specification. The aim is to allow initiating applications a flow to signal a 'login as' intent as well as an 'open this resource' intent to the receiving application.

[jeswr]

When this is read without the context of the demo given in the Solid CG, it can be hard to imagine the expected flow. I would recommend describing the flow of the demo - in addition to having the flow diagram described in the meeting, so that the intended behaviour can be understood.

[uvdsl]

This PR was discussed on the 2026-07-01 meeting, including a quick rundown of the demo.

[elf-pavlik]

Two recommendations for sequence diagrams

• Mermaid as in https://github.com/solid/solid-oidc/blob/main/sequence.mmd - very simple and github can render it everywhere
• LikeC4 as in https://elf-pavlik.github.io/lws-auth/view/oidc/?dynamic=sequence
  This one can be navigated step by step and show rich Markdown notes, eventually Solid-OIDC primer could have an optional representation like that. I'll be working on reusable LWS model in LikeC4 to also reuse it for Create Threat Model Note w3c/lws-protocol#177

[Potherca]

in addition to having the flow diagram

Something like this?

[Potherca]

Also, this discussion already talks about the scenario for opening resources: pod-os/PodOS#47

[Potherca]

Also also, as the intent is an instruction for the client-side code and not the server, I think that using a hash # would be more fitting than using query params (as those are meant as instructions for the server).

This would also prevent the WebID (or other values) from being visible server-side (in logs, etc.) which is better from a privacy perspective.

[elf-pavlik]

Does the initiating application construct url with parameters? If it does how would it decide to use query or fragment? The whole idea of having parameters in a fragment doesn't sound familiar to me. Do you have examples of it being used elsewhere?

[Potherca]

Originally, the intent was to only support the fragment #, as that avoid more complexity (like capability discovery).

Concerns were raised that this would not work with server-side apps, which I disagree with.

From my perspective, intent only makes sense for a UI. The UI for a server-side app could easily convert the # to a ? and do a URL reload to trigger the server, without the need for supporting both fragment and query parameters.

Regarding

Do you have examples of it being used elsewhere?

Besides generic patterns of single-page applications (SPA) for things like #q=foo&type=bar&filter=baz, there are various apps and protocol that use fragments with the explicit goal of avoiding parameters from reaching the server. Either because they are secret or because the server would not know what to do with those params.

For instance... (click to toggle details)

• Excalidraw uses fragment parameters for share URLs: https://excalidraw.com/#json=SvgTAQvEpfAAwYdFqFhy1,kT7-izZXZFSgAIxQ9TctGw

• Kibana (Elasticsearch dashboard) uses fragment parameters for app state: https://your-kibana-domain:5601/app/discover#/?_g=(refreshInterval:(pause:!t,value:0),time:(from:now-15m,to:now))&_a=(columns:!(message),filters:!())

• M$ Teams uses fragment parameters for streaming initialization context: https://teams.microsoft.com/_#/?ctx=chat&tenantId=xxxx-xxxx-xxxx

• OAuth 2.0 Implicit Grant Flow (now deprecated) uses fragments for it's Access Token Response RFC 7111

• RFC-5147 uses fragments to refer to parts of a text file by character or line position (or range): http://example.com/text.txt#line=10,20

• RFC-7111 does the same but with by row, column, or cell, for CSV files.

• vdo.ninja (previously bdo.ninja) uses fragment parameters to hide Stream IDs and Room Names from the server: https://vdo.ninja/?push=cam1#p=secret&token=abc123&key=xyz

• YouTube video player uses fragment parameters for player instructions: https://www.youtube.com/watch?v=dQw4w9WgXcQ#t=90&autoplay=1&cc_load_policy=1

• etc.

[elf-pavlik]

Thank you for the diagram @Potherca I think I understand the intent (no pun intended!).

My main issue is that in my idea of a default state of things, applications don't know anything about any other applications that the user is using - privacy concern. Even if they know they shouldn't be disclosing any information to other applications, specifically information which isn't publicly available via user's WebId.

I recall some prior conversations about 'open with' style interactions. The only link I can find now solid/catalog#24

While we can't assume that any application used by a user knows anything about any other application used by that user. At least SAI and MANDAT have notion of Authorization App/Agent, which is special case app/service with hight trust from the user. In https://sai.js.org I actually combine it with the IdP itself, but they could be separate. Whatever flow we design should accommodate for possibility of user having such special app/service, in SAI it is advertised in WebID, similar to OIDC Issuer. And flow may need to go through that special party.

Can we pick 2-3 specific, real world use cases and walk through them

1. without this proposal
2. with this proposal
   a) as of now
   b) extended to a special trusted app/party incorporated in this flow to avoid privacy leaks between applications

I'm happy to work on the same use cases with approach 2b.

@jg10-mastodon-social @srosset81

[jg10-mastodon-social]

Here's what I had been working on:
https://jg10.solidcommunity.net/open-with/databrowser-open-with.html

We indeed agreed that apps should not need to have knowledge of what other apps a user is using.

Given the state of things, I moved to working on a less normative guide, still a WIP:

https://jg10.solidcommunity.net/open-with/guide.html

We hadn't covered auto-login/webId specification.

On Solid Focus (which now supports auto-login), we had talked about linking to other resources and deep linking to a task

[jg10-mastodon-social]

question: How would an initiating application discover the capabilities of the receiving application?

suggestion: I would prefer to use only query parameters

[Potherca]

I would prefer using only fragment parameters.

As the intent is an instruction for the client-side code and not the server, I think that using a hash # would be more fitting than using query params (as those are meant as instructions for the server).

This would also prevent the WebID (or other values) from being visible server-side (in logs, etc.) which I think is better from a privacy perspective.

[jg10-mastodon-social]

The reason I would prefer to use query parameters is that its a standard way of passing values for parameters, whereas fragments identify a specific part of the resource.

How would you handle opening a url that already has a fragment?

[uvdsl]

As the intent is an instruction for the client-side code and not the server,

I do see the argument of an SPA not accidentally leaking information on the host server logs.
If however the client has a BFF, I think the information are transmitted to the server-side component anyway for authentication? (but that is on purpose then, so probably fine anyway)
And if the app is fully server rendered, I am unsure whether this would work using only fragments?

That asked, there is indeed prior art to having parameters in the fragment, see W3C REC of Media Fragments URI 1.0 (basic). Maybe worth a look regarding their approach and reasoning.

[jg10-mastodon-social]

suggestion: open would presumably imply login, and the presence of a webId or resource would presumably imply login and/or open with respectively. The intent parameter could therefore be removed/optional unless there are specific future plans for it?

[jg10-mastodon-social]

suggestion: this would presumably be a special case of solidResource, and if needed the fact that it is a storage could be confirmed using https://solidproject.org/TR/protocol#storage-resource

[csarven]

Pardon me as I couldn't review this earlier.

Signalling who to log in as or what to open when handing a user over to another application is a real need. I want to support them, with a suggestion and a few concerns.

Suggestion: consider converging with Application Capability, proposed as a work item in #806, draft: https://dokieli.github.io/application-capability/ . It covers this draft's use cases: login and open are defined invocation variables, carried in a URI Template that the receiving application publishes in a discoverable description. Different kinds of capabilities and invocations can be created (beyond what's in the spec, see the Invocation Extension section). Discovery also fixes a gap here: an initiating application cannot know which parameters or which form (query or fragment) a receiver supports, so pairings end up hardcoded. If you have needs it does not yet cover, I'd rather we capture them there together than maintain two overlapping mechanisms. As explained elsewhere Application Capability goes much further than URI Templates for intending/invoking/triggering/hinting... and we need to look at this as part of a bigger picture.

In RFC 3986, the query is part of what identifies a resource, and per RFC 9110 it is sent to the server. So ?intent=login&solidWebId=... discloses the user's identity and target resources to the receiving host, its logs, and intermediaries. The MUST for server-side applications normalises this, and there are no security or privacy considerations discussing it. See URI Query, URI Fragment, and the Threat Model for how AC approaches this.

Regarding Solid-specific naming, the solid* prefixes bake one ecosystem into the wire format, while section 5 itself says the mechanism is not unique to Solid. These are all just IRIs; generic names travel further.

solidIdp and solidStorage are discoverable from the WebID profile (solid:oidcIssuer, pim:storage). Passing them duplicates authoritative data and enlarges what is disclosed per invocation. The agent's URI is enough; the rest follows by discovery.

None of this is a "no" to the use cases. There is implementation experience covering them on the AC side, and I would welcome working on this together.