Re: LWS Auth(N&Z) - full sequence diagram (first draft)

Hello Pavlik,

Thank you for putting this together. Your diagram is a really nice
illustration of the proposed authN and authZ flows. One important aspect of
your diagram that I would highlight is the way it identifies the different
security domains: user, client, and storage. This is a key part of the
intended design.

The use of an ID-JAG is a nice touch. As you know, we can't normatively
reference that, since it is still an IETF draft, but there is enough
flexibility built into the protocol to support that type of interaction.

One item to mention about the diagram is that it uses a WebID profile
document, which we also cannot normatively reference. Instead, the proposed
LWS auth protocol expects that these resources will be Controlled
Identifier Documents. We have been thinking that a server that currently
supports WebID profile documents as TURTLE could content-negotiate
resources to a conforming CID, while retaining the important values
required for authentication and authorization. The goal is that a system
that currently supports Solid and WebID could be adapted to also support
LWS authentication.

Best,
Aaron

On Tue, 25 Nov 2025 at 20:30, elf Pavlik <elf-pavlik@hackers4peace.net>
wrote:

> Hello,
>
> I created a rough first draft of a sequence diagram showing theoretical
> full sequence from user authenticating with an application to viewing a
> protected resource.
> https://elf-pavlik.github.io/lws-auth/view/oidc/?dynamic=sequence
>
> (start button allows stepping through the sequence with notes for each
> step)
>
> I would like to have available something similar to
> https://solid.github.io/solid-oidc/primer/
> which I believe many developers found to be a useful reference.
>
> This early draft is based on the two PRs
> * https://github.com/w3c/lws-protocol/pull/43
> * https://github.com/w3c/lws-protocol/pull/45
>
> As well as those IETF drafts
> *
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-01.html
> *
>
> https://www.ietf.org/archive/id/draft-parecki-oauth-client-id-metadata-document-03.html
>
> All token audiences are restricted and tokens are not sender
> constrainted (no DPoP).
> I didn't have a good way to capture that Resource Owner security domain,
> in real life would be repeated n times, once for each storage (server)
> of each peer in a social graph whose data the app is accessing.
>
> There are a lot of issues, especially in snippets I need to do more
> checks on all the `aud`, `realm`, `resource` use etc.
> At this moment I would mostly be interested in high level feedback.
> * Does it follow intented use as of current LWS PRs?
> * Does the way I try to incorporate Identity Assertion JWT Authorization
> Grant is somehow reasonable?
> * Does the overall format even looks useful - I'm using open source
> library https://likec4.dev/
>
> I'll be iterating over it in next days/weeks, eventually hoping to use
> it as a reference when looking myself and discussing with others how it
> could be implemented in CSS and open-source client libraries.
>
> Best regards,
> elf Pavlik
>
>

-- 
This e-mail, and any attachments thereto, is intended only for use by the 
addressee(s) named herein and may contain legally privileged, confidential 
and/or proprietary information. If you are not the intended recipient of 
this e-mail (or the person responsible for delivering this document to the 
intended recipient), please do not disseminate, distribute, print or copy 
this e-mail, or any attachment thereto. If you have received this e-mail in 
error, please respond to the individual sending the message, and 
permanently delete the email.