LWS Authorization

[acoburn]

This is a companion to #43, outlining authorization in LWS.

This is also a class 4 change and will require WG discussion and vote before merging.

This PR follows from discussion on 2025-10-09 during which the attendees described the outline of an authentication mechanism for LWS. As discussed during that meeting, this proposal leaves the definition of a policy language out of scope.

---

Preview | Diff

[elf-pavlik]

LGTM and seems pretty close to Solid-OIDC interop between Client, AS and RS.

[elf-pavlik]

Would it make sense to mention the realm here as well?

[acoburn]

That's a good idea to connect this to the realm value from WWW-Authenticate. See the change in aa26ca4

[elf-pavlik]

Following on #43 (comment)
It might be useful to indicate that the Resource Authorization Server is specified here. Not the IdP Authorization Server, especially given that both may be doing token exchange.
Even that this spec is not coupled with any specific authentication suite, it might still be useful to establish this distinction here.

[w3cbot]

This was discussed during the #lws meeting on 08 December 2025.

View the transcript

Authorization discussion

<acoburn> w3c/lws-protocol#45

<gb> Pull Request 45 LWS Authorization (by acoburn)

acoburn: there has been some engagement already on this PR
… this is an attempt to bring Solid more fully under the OAuth authz scheme
… [showing the diagram]
… how Solid works today, is that the ID token is used as authorization token
… idea is, to take Solid what it currently does, and bring closer to how OAuth works
… i.e., having a dedicated authorization server
… issue with using global ID tokens: a storage getting an ID token could reuse that token. that's why DPOP was added, but that adds complexity
… idea is that we move that complexity elsewhere
… so the application could take an identity credential (could be an OIDC ID token, could be SAML, etc)
… which gets exchanged for an access token
… this is used by the storage
… that storage cannot reuse that token
… we're putting all that token exchange as part of the authorization server
… its functionalitites: verify the identity token, that the token is scoped correctly, etc

<Zakim> gibsonf, you wanted to ask about AS

gibsonf1: on the authz server: you're saying 'this ID token is for this storage'?

acoburn: it's an exchange
… from an authn token to an access token
… once the access token is sent to storage, you can see 'can this particular user access this particular resource?'

<Zakim> TallTed, you wanted to ask whether the mentions of Solid here are as a prototypical implementation of LWS

TallTed: is Solid mentioned as prototypical implementation of LWS?
… otherwise we'll get in trouble down the road

acoburn: yes, indeed, Solid is brought to center the conversation
… so it gives a migration path, and we don't discuss anything brand new
… we are not saying 'this is what solid does, so this is what lws does'

pchampin: why is it better to send it to the AS instead of the storage?
… what do we gain here?

acoburn: we mainly gain that we align with OAuth
… we use the OAuth protocol to gather a real access token and use it as an access token
… instead of trying to reuse an ID token as an access token

<Zakim> bendm, you wanted to say we also gain separation of concerns (cfr data spaces)

<pchampin> that makes sense, thanks a lot

bendm: the advantage of passing the ID to the authN server is that you get a separation of concearns

bendm: so, eg, you can have a set of storage servers managed by one AS, where you only need to trust the AS, not all individual storage serves

acoburn: also, you could have a SAML assertion, that you can exchange for an access token
… so you could combine the signed XMLs with JWTs
… also, the AS could supports many different types of credentials
… meanwhile, being able to consolidate the functionality of an access token

<elf-pavlik> https://elf-pavlik.github.io/lws-auth/view/oidc/?dynamic=sequence

elf-pavlik: this sequence diagram
… what I tried to emphasize are the security domains
… in OAuth, access tokens should not cross security domains
… in Solid, global access tokens were used, even broader than id token
… now, we can go to UMA or OAuth token exchange
… this diagram shows the different security domains
… this diagram also introduce another token exchange: from id token to access token of your own AS, to access token to the storage server's AS
… it's a bit more chatter, but compliant

<dmitriz> I think this might be adding a bit more complexity than maybe we need?

acoburn: about sender-constrained: other than DPOP, we use the audience claim very loosely
… in a JWT, `aud` is used to constrain the token
… this interaction allows to use the audience constraint to make sure these tokens don't become global

dmitriz: let's make clear which problem we're solving
… alignment with what other protocols were meant to do, is not a great argument
… e.g. OAuth 2 has recently gotten the client metadata document
… which is the result of a multi-year conversation, inspired by WebID documents
… the other direction to consider, is to work to update the OAuth and OpenID specifications

acoburn: it's fair to ask "what about aligning OAuth with LWS?"
… however, having OAuth change seems like a very big ask
… which doesn't seem realistic with our timeline

dmitriz: what I mostly want to say: I want us to be very clear what extra complexity is really needed

acoburn: what elf was talking about: there could be intermediate token exchange, but those will be deployment and use case specific
… they don't directly apply to LWS
… the main reason is to have access tokens, aligning with OAuth is a good to have

elf-pavlik: everyone says 'use existing authn/authz protocols, don't invent your own'
… in CSS, okta libraries are used, and that's a good thing
… cfr. about the additional token exchanges: that's for sender-constrained access tokens
… other extensions are also possible, eg for client applications

dmitriz: why not just sender-constrain the dpop tokens?

elf-pavlik: because dpop is used for access tokens, and access tokens should not cross security domains
… we could ask IETF to extend the dpop definition, but, e.g. for app authorization we need another way
… we just need some way to create sender-constrained tokens

acoburn: this interacts with the authentication proposal:
… for every authentication suite, you must have a token type uri
… it must be from iaana
… e.g. saml2 or oidc token
… (it SHOULD be from IANA, but it MUST be an URI)
… so e.g., for WebID, we must define a URI that covers that kind of credentials
… AS should broadcast what type of tokens they support (eg JWT or ID Token)
… using the `resource` parameter, you can restrict the token to a single storage

acoburn: so please have a look that the PRs
… most is on section 5, and there are some security and IANA considerations
… if there's consensus, I'd like to merge these in 2025
… so, by next meeting

---

[pchampin]

I'm not an expert of RFC8693, but it seems to me that some of these requirements are directly "inherited" from RFC8693, while others are specific to LWS. It might be useful to clearly mark the difference.

[pchampin]

the token is not the same as in the previous example. Is this deliberate?

While it is not clearly stated that this is a running example, I was assuming so far that the examples were making a consistent narrative.`

[acoburn]

This wasn't explicitly intended as a running example, but that is a good idea

[acoburn]

See #51 for an adjustment of the access token so that this can be viewed as part of an authorization flow in a single session.

[pchampin]

This section contains a number of normative text (MUST, SHOULD). However, the "Security & Privacy Consideration" sections are usually non-normative -- they are "considerations". Furthermore, some (if not all?) of the MUSTs and SHOULDs of this section are in fact repetitions of normative statements contained elsewhere in the spec (which is good).

I suggest to rewrite this section, pointing to the appropriate normative statements rather than repeating them -- and if some of the MUSTs and SHOULDs in this section are not reflected anywhere else, they should be moved, and again simply pointed too in this section.

[acoburn]

Agreed. I will plan to rework that section after this PR is merged

[acoburn]

See #50 for a reworking of the security considerations

[ebremer]

https://www.iana.org/assignments/oauth-parameters/

[ebremer]

https://www.iana.org/assignments/well-known-uris/

[ebremer]

I don't see anything that should block the merge of this.