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?

[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