Meeting minutes
Introductions and announcements
ericP: we have guest star Elf Pavlik, specifically for authorization
elf-pavlik: I have been working on Solid-OIDC, and implemented other draft, and on SAI
… which deals with app authz specifically
… and I'll work on a Solid Symposium session on authz and security
… I also created a sequence diagram for the current PRs
… happy to be here!
ericP: at some point, I want a session on SAI
Authentication questions from last week
<acoburn> w3c/
<gb> Pull Request 43 LWS Authentication (by acoburn)
acoburn: I wanted to raise this agendum as we talked last week mostly on authn
… so if anyone has any remarks that isn't part of the PR yet, go ahead
dmitriz: what is the outcome of last week's call?
acoburn: this PR describes an abstract framework for having an authentication suite
… and specifies some concrete suites
… one shows how it would be used with SAML
… mostly to show that it's possible
… another suite using client credentials, another using DIDs
… showing the way it works and what the basic components are
… we hope that next monday we can have a vote on authn and authz
… so that we can begin building on that
elf-pavlik: I noticed on FED-ID slack, they're discussing that
… they kind of agreed that SAML might be more supported than OIDC, which is a nice data point
… what's the plan for testing, and what's the feedback from implementers?
… eg solid-OIDC was only implemented in JAVA in Inrupt
jeswr: Dmitri: is this specification in any way aligned with Social Web WG?
… could we have something that could be implemented by both?
dmitriz: good question
… Social Web space mostly uses combination of OAuth for client API and httpsig for server-to-server authn
… they don't have implementations of oidc
<Zakim> ericP, you wanted to say that i'd probably require a toy authN for the test suite
dmitriz: we could present it, some implementations might find it useful
elf-pavlik: the main difference with activitypub, is that the client connects to more servers than only the user's server
… in activitypub, it feels more like client-client server, then more server to server
… in Solid, I understand Christoph's work using a proxy-based approach, which is closer to how activitypub works
… it feels a bit as a gap between both architectures at this point, I think
ericP: regarding testing, we can have a toy authn/authz scheme
… like they did for SPARQL
… if we include authn or authz as more than a note (i.e. as a REC), then we must test it
Authorization discussion
<acoburn> w3c/
<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: 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
CRUD & Metadata proposal
acoburn: there's another proposal from eBremer
… on CRUD and metadata
<acoburn> w3c/
<gb> Pull Request 37 Initial CRUD with proposed metadata handling (by ebremer)
<Zakim> elf-pavlik, you wanted to discuss authz apps
<elf-pavlik> https://
elf-pavlik: can we discuss authorizing applications?
… eg the aud tag could provide scopes
… so client applications (the server needs to allow something that the application wants, not necessarily something that the user wanted)
… is an interesting follow up topic
eBremer: about the crud PR
… 7 describes the functionalities, going into 8, and 9 specifies the mapping
ericP: see you next week, please review the PRs, and next week we vote on authn and authz
acoburn: and 2025-12-15 is the final LWS meeting of 2025, next one will be January 5th