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]

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