07:45:01 <RRSAgent> RRSAgent has joined #lws
07:45:05 <RRSAgent> logging to https://www.w3.org/2025/10/09-lws-irc
07:45:05 <Zakim> RRSAgent, make logs Public
07:45:06 <Zakim> please title this meeting ("meeting: ..."), pchampin
07:45:13 <bendm> bendm has joined #lws
07:45:23 <bendm> present+
07:45:24 <bartb> bartb has joined #lws
07:45:31 <Beau> Beau has joined #lws
07:45:41 <Beau> present+
07:46:03 <Wonsuk> Wonsuk has joined #lws
07:46:13 <pchampin> Topic: Action items
07:46:55 <pchampin> s/Action items/Agenda
07:47:05 <pchampin> laurens: we will start action items from yesterday, assigning people who want to refine the questions we discussed
07:47:11 <pchampin> ... then discuss Authorization
07:47:23 <Wonsuk> present+ Wonsuk_Lee
07:47:34 <pchampin> ... In the afternoon, we will discuss authentication, and continue the discussions on core operations
07:47:53 <pchampin> ... then we will set a road map and further discuss action items
07:48:33 <pchampin> Topic: Action items from yesterday
07:48:51 <pchampin> aaron: we discussed a couple of topics, and seem to have general consensus on how to express this in specifications
07:48:54 <laurens> laurens has joined #Lws
07:49:03 <laurens> present+
07:49:17 <pchampin> ... the next step would be to have some text that the whole group could discuss, before merging it
07:49:40 <pchampin> ... we could start with PRs on the spec, or with issues, depending on how complicated the topic is
07:49:54 <pchampin> ... we should have a person responsible to each topic
07:50:01 <pchampin> ... - a section that describes the conceptual entities
07:50:12 <pchampin> ... - a section that starts to unpack the type index
07:50:59 <pchampin> For the type index I believe that definitions need to be clarified, so better start with an issue
07:51:14 <pchampin> s/For the/... for the
07:51:32 <pchampin> ... I can take the first one. I'll probably go with several PR, one for each entity kind
07:51:43 <pchampin> ... I'm not convinced that the names will remain
07:52:00 <pchampin> ... This would provide an outline for the main parts of the specification
07:52:16 <pchampin> laurens: yes, then additional PRs could be proposed on each section
07:52:44 <pchampin> ... I would have a section with conceptual entities and abstract operations
07:52:53 <pchampin> ... then another section with RESTful implementation of these operations
07:53:58 <pchampin> aaron: the HTTP bindings would be in a separate PR (even though HTTP operations can be informally mentioned in the abstract operations)
07:54:30 <pchampin> ben: I expect that discussion on metadata will be more extensive
07:54:34 <pchampin> aaron: I agree
07:55:03 <pchampin> ... a lot of what we have been discussing, especially the linked data features, will be important for the metadata
07:55:13 <laurens> laurens has joined #lws
07:55:33 <pchampin> ben: we don't need to follow how Dropbox or Google drive are doing things, but it can be a good source of inspiration
07:56:08 <pchampin> ... we should look at existing APIs to decide what we want to take from them as inspiration
07:56:17 <pchampin> ... I can do this research
07:57:08 <pchampin> aaron: Erich Bremer has already written something about metadata, largely based on linksets
07:57:17 <pchampin> ... I expect this to be a big part of the section on metadata
07:57:32 <pchampin> ben: updating metadata can have a number of side effects (like renaming, moving...)
07:57:52 <pchampin> aaron: I'm hoping we can discuss details about metadata before we get into authorization
07:58:04 <pchampin> ... Is anyone interested in taking the lead about the type index?
07:58:13 <pchampin> laurens: I can try that
07:58:54 <pchampin> ... there might be relations to LDES, or even other ontologies
07:59:24 <pchampin> aaron: there was two thing I was hoping to discuss yesterday
07:59:33 <pchampin> ... - the structure and data model of containers
07:59:37 <pchampin> ... - other kinds of metadata
08:00:28 <pchampin> eric: I prefer to start with containers, this would ground our conversation on metadata
08:00:34 <pchampin> sutopic: Containers
08:00:50 <pchampin> aaron: the current spec says the containers are RDF
08:01:00 <pchampin> ... no guidance about JSON representation, about what properties to include
08:01:15 <pchampin> ... no facility for extremely large containers that you might want to page through
08:01:44 <pchampin> ben: another one is the need to list the files without needing access to them
08:02:20 <pchampin> laurens: what's important to me: paginating the "contains" relationships
08:03:02 <pchampin> ... there's the question of what other metadata we want to include
08:03:14 <jeswr> jeswr has joined #lws
08:03:15 <pchampin> ... some metadata are part of system-management
08:03:22 <jeswr> present+
08:03:40 <pchampin> ben: should it include something like "controller"?
08:04:18 <pchampin> laurens: that's tricky to define. Could be several people? Should this be the owner?
08:04:43 <pchampin> bartb: by owner, do you mean the owner of the whole pod?
08:05:39 <pchampin> laurens: we are veering into the authorization discussion, this is a complicated subject
08:06:23 <pchampin> ... another metadata is type. Should it be system- or user-manage, or both?
08:07:09 <pchampin> aaron: imagine you want to list only the JSON files in a container. With opaque names, you need a HEAD on each resource, not practical.
08:07:39 <pchampin> [aaron writes some JSON-LD on the paper board]
08:08:38 <pchampin> ... without presuming the exact format we will use for containers, we will have a list of "items"
08:08:56 <pchampin> ... each object in this list may contain the id of the resource
08:09:48 <ericP> ericP has joined #lws
08:09:57 <ericP> present+
08:10:00 <pchampin> ... a type, which would  be an array containing system defines (e.g. "Container") and user-defined (which may be set via the metadata)
08:10:35 <pchampin> ben: could be multiple, could be 50,000
08:10:50 <pchampin> aaron: could be, though servers could add constraints on this
08:10:58 <pchampin> ... items could have a size value, last-modified, created
08:11:21 <pchampin> ... in principle, any item in the link-set metadata could just be here
08:11:50 <pchampin> laurens: and what would be present could be negociable by the client
08:12:06 <pchampin> aaron: yes, with Prefer: headers. LDP does that, I like it, but I'm not sure how widely this is used.
08:12:43 <pchampin> ben: this would be ACL managed, right? the list is generated based on your permissions?
08:13:28 <pchampin> laurens: it should be. Note that having read access to a container should probably allow you to see what's in it.
08:13:39 <pchampin> aaron: I've worked on 2 LDP servers that did things differently
08:14:12 <pchampin> ... Fedora had an ACL aware container. If you have access to only 1 of the 3 items in a container, the 2 other entries would be there but obfuscated.
08:14:25 <pchampin> ... There is a huge performance penalty for that.
08:15:07 <pchampin> ... The other approach is: if you have read access to the container, you can see all that it contains.
08:15:12 <ryey> ryey has joined #lws
08:15:15 <ryey> present
08:15:34 <pchampin> ... If you have privacy concerns, you can use a 2-levels hierarchy.
08:15:58 <pchampin> ben: 2nd option seems reasonable
08:16:11 <ericP> q+ to geek about the interminable 401/404 debate
08:17:24 <pchampin> rui: could there be a middle-ground, with 2 read permissions for containers?
08:17:36 <pchampin> laurens: I suggest we park this for the Authorization discussion.
08:17:47 <pchampin> ... but this middle-ground already exists.
08:19:02 <pchampin> ... Also, changing the view of the container based on your permissions on the contained resource makes its hard to cache.
08:19:05 <ericP> q-
08:19:21 <pchampin> ericP: is this the same problem with the type index?
08:20:00 <pchampin> ... if someone makes a resource confidential, it would have an impact on the type index and on the container.
08:20:04 <ryey> present+
08:20:11 <pchampin> ... Same caching issues.
08:20:29 <pchampin> laurens: for me the type index is eventually consistent, different from containers. Maybe others have other expectations.
08:20:51 <pchampin> ericP: I guess some people might want to debate that.
08:22:02 <pchampin> ... My point is: we may need to consider the issues on containers and the issues on type index all at once.
08:22:43 <pchampin> ben: you can still use  sub-container to hide confidential resources
08:23:07 <pchampin> ericP: this forces people to use a specific organization of their resources
08:23:37 <pchampin> laurens: what is the meaning of the READ permission on a container?
08:23:54 <pchampin> ericP: I would argue that to see an item in the container, you need READ persmission on both the container and the item.
08:24:12 <pchampin> ... I wonder if the performance issues mentioned by Aaron were implementation issues, or deeper.
08:24:54 <pchampin> aaron: back to serialization, I would like to discuss which metadata are part of the container's description
08:25:28 <pchampin> laurens: I would expect a "containedBy" link available on the resource
08:26:43 <ericP> scribe+
08:27:10 <ericP> pchampin: shoud the container include the media type plus the RDF type?
08:27:13 <ericP> scribe-
08:28:22 <pchampin> ben: I would suggest 3 different properties for different kinds of type: LWS type (container/resource), media type, additional types
08:28:45 <pchampin> rui: how do we get the media type?
08:29:02 <pchampin> aaron: I would expect that the server keeps track of the media type of each resource
08:29:10 <pchampin> ... this is a MUST in the current Solid spec
08:29:56 <pchampin> ben: back to the Prefer: header, this could be used to deal with the scalability when we have a large number of types
08:30:41 <pchampin> aaron: I think this discussion will be informed by the higher level discussion on description format
08:31:05 <pchampin> ... Activity Streams has a notion of Collection, LDP has a notion of container
08:31:33 <pchampin> laurens: I would avoid overloading LDP containers, I suspect we are going to diverge from it
08:31:47 <pchampin> ... but I appreciate the need to be backward compatible
08:32:27 <pchampin> aaron: I expect that we will define a JSON-LD context for LWS, which could include the AS context
08:32:42 <pchampin> ... so we will reuse existing vocabulary when available
08:33:11 <pchampin> ... for last-modified and created, probably Dublin Core
08:33:30 <pchampin> laurens: is there something for size?
08:33:45 <pchampin> jeswr: stat:size is already in the spec
08:33:58 <pchampin> aaron: but stat: is explicitly for POSIX filesystems... talk about overloading
08:34:08 <pchampin> ben: defining our own terms is not that bad
08:35:35 <pchampin> aaron: I would include a size predicate; I would make it a SHOULD because exposing the size of large files could be a security issue (attack target)
08:35:51 <pchampin> ... and only for non-container resources
08:36:00 <pchampin> ... id would be a must
08:36:27 <pchampin> laurens: as well as resource type and media type
08:36:46 <pchampin> s/be a must/be a MUST
08:36:58 <pchampin> ... all the rest would be SHOULD, imo
08:37:32 <pchampin> rui: the size is not the only one that would be security sensitive, names can sometimes be
08:38:00 <pchampin> aaron: that's why I would suggest most metadata would be SHOULD
08:38:15 <pchampin> bartb: also, some resources might be generated, so the size is not known in advance
08:38:31 <pchampin> aaron: that's a good point. We may have a notion of "projected resource", or views.
08:39:55 <pchampin> pchampin: as we are discussing MUSTs and SHOULDs
08:40:16 <pchampin> ... I suggest that we not only make JSON-LD contexts but also JSON-schemas of sorts for the LWS serializations
08:40:29 <pchampin> ... more friendly to developers who are not comfortable with Linked Data
08:41:01 <pchampin> ben: I would also suggest a "label" field
08:41:12 <pchampin> jeswr: why put it here rather than in the metadata resource?
08:42:02 <pchampin> ben: yes, I'm mixing the two, but the metadata in the container are related to the metadata of the data resource
08:42:34 <pchampin> jeswr: I would suggest that the user-defined types are more appropriate for the metadata than for the container medatata
08:43:20 <pchampin> rui: every metadata should be in the metadata associated resource (except maybe size)
08:43:47 <pchampin> ... and in this associated resource, you would specify which would show in the containers
08:44:06 <pchampin> ben: that's what I was suggesting
08:44:50 <pchampin> jeswr: this raises the question of the resource-level metadata that you are authorized to see
08:47:31 <pchampin> pchampin: LWS containers and AS collections are similar, but we need more discussion; they should maybe not be conflated
08:47:42 <pchampin> subtopic: Resource-level metadata
08:47:52 <pchampin> RRSAgent, make minutes
08:47:53 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/09-lws-minutes.html pchampin
08:48:42 <pchampin> aaron: Erich Bremer has written some text, based on RFC 9264 (LinkeSet resources)
08:49:03 <pchampin> ... it follows the RFC 8288 (Web Linking)
08:50:02 <pchampin> ... a link has a target (a URI), a relation type ('rel=...'), and a number of relation types are predefined
08:50:15 <pchampin> ... additionally, a link can have a title (text)
08:51:08 <pchampin> ... you can put an arbitrary URI in the rel= attribute
08:51:32 <pchampin> ... LDP defines its own relation types as URIs
08:52:00 <pchampin> ... this relying on LinkSet puts constraints on what could be in the metadata
08:52:29 <pchampin> ... adding properties to the link is allowed but not recommended
08:52:49 <pchampin> laurens: one problem is that Web Linking only expects URIs as the target of the links
08:53:39 <pchampin> aaron: the title attribute allows for text, title* allows for internationalized text
08:53:56 <pchampin> pchampin: but that's an indirection, that "the title of the target itentified by the URI"
08:54:21 <pchampin> meeting: LWS WG Face-to-Face Meeting (Day 2) – 09 October 2025
08:54:42 <pchampin> laurens: we discussed yesterday about opaque identifiers
08:54:52 <pchampin> ... this would make it important to be able to add user-friendly labels
08:54:56 <pchampin> ... which this method can not capture
08:55:29 <pchampin> ... an RDF document with the resource as primary topic would be more flexible
08:55:46 <pchampin> aaron: the advantage, on the other hand, is the ability to convey the metadata as link headers
08:56:17 <pchampin> laurens: there is also the question of server-managed vs user-managed
08:56:56 <pchampin> ... with RDF, system-managed could be enclosed in a named graph, making things easier for developers
08:57:11 <pchampin> aaron: I get the point about labels and literals
08:57:23 <pchampin> ... about server-managed, I don't think there would be too many of them
08:58:09 <pchampin> ... namely: describes / describedBy, acl (potentially)
08:58:30 <pchampin> ... the current specification has a relation to the root of the storage; that also would be server-managed
08:58:49 <pchampin> ... also a relation pointing to a storage description would be server-managed
08:59:06 <pchampin> ... apart from that, I think everything else is good for users to manipulate
09:00:20 <ericP> q+ to say that LDP Containers did double duty as server-managed and user-managed containers. if we want to enable both UML:owned members and polyhierarchy, we might want to consider the user-managed containers as their emulations of the server Container interface, but entirely not our problem
09:00:20 <pchampin> pchampin: could we simply add spurious attributs to the LinkSet documents, where we would shove some JSON-LD with literal properties?
09:00:31 <pchampin> aaron: I re-read the spec, they discourage that
09:01:18 <pchampin> ... Note that if you have a binary object that can not self describe and you want a rich set of metadata about it
09:01:42 <pchampin> ... I would encourage that you create a data resource that is RDF, and then you link to that as "additional description"
09:02:20 <pchampin> laurens: that's what I discussed yesterday with additional secondary resource
09:02:54 <pchampin> rui: I'm looking at RFC 9264, we need to serialize this to JSON
09:03:40 <pchampin> aaron: the RFC defines 2 formats, one of them is JSON. We would require the JSON, we would authorize contebnt-negotiation to Turtle
09:03:55 <pchampin> laurens: but updating the resource should use the JSON standard format
09:04:07 <pchampin> aaron: I would not prevent SPARQL update of the resource, but not require it
09:04:47 <pchampin> ericP: you can do a PUT with an etag, the etag depending on the serialization
09:05:42 <pchampin> ben: aren't we painting ourselves in a corner with this serialization? shouldn't we discuss what metadata we need more generally first?
09:06:17 <pchampin> ... the ability to convey the metadata in HTTP Link headers is an optimization
09:07:10 <pchampin> aaron: you are right
09:07:28 <pchampin> ... start with describes / describedBy, linking between a resource and its metadata resource
09:07:45 <pchampin> ... acl
09:07:51 <pchampin> ... parent
09:08:05 <pchampin> rui: is parent an array or a single value?
09:08:56 <pchampin> aaron: type (server defined, e.g. container/resource)
09:09:00 <pchampin> ... media-type
09:09:23 <pchampin> ... label (a.k.a. user defined type)
09:09:57 <pchampin> ... storage
09:10:14 <pchampin> ... storage metadata
09:10:56 <pchampin> laurens: about 'storage metadata', could be discoverable with .well-known (like OpenID)
09:11:15 <pchampin> aaron: as we are doing linked data, I prefer explicit links
09:12:39 <pchampin> laurens: acl would be server managed in most implementations, even though there is a slight chance that some implementations would want to allow users to set it
09:14:15 <pchampin> aaron: I imagine that we can define a number of mandatory fields, users could add their own
09:14:27 <pchampin> laurens: server implementations could also
09:14:34 <pchampin> beau: I suggest adding a link to a shape file
09:14:46 <pchampin> aaron: +1, although I would suggest "schema"
09:15:42 <pchampin> rui: label should be renamed to user-defined-type
09:15:53 <pchampin> ben: but a text label property should be there
09:17:57 <pchampin> Wonsuk: having a version marker would be useful, because the metadata format may evolve
09:18:15 <pchampin> jeswr: could be achieved by a version number in the JSON-LD context
09:19:25 <pchampin> pchampin: I like aaron's suggestion earlier "additional-medatata" (a data resource that further describes the resource)
09:20:31 <pchampin> rui: about 'parent', should the concept of "transitive container" be possible?
09:20:39 <pchampin> jeswr: this has impact on authorization
09:21:14 <pchampin> aaron: if A contains B contains C, the metadata for C would say: "parent=B", it would not talk about A
09:21:50 <pchampin> ... one might allow an alias of a resource to be in multiple containers
09:23:03 <pchampin> aaron: maybe we could have a "hierarchy" field that gives an array of all ancestors, from direct parent to storage root
09:23:13 <pchampin> ... could be useful
09:23:18 <ericP> ack me
09:23:18 <Zakim> ericP, you wanted to say that LDP Containers did double duty as server-managed and user-managed containers. if we want to enable both UML:owned members and polyhierarchy, we might
09:23:21 <Zakim> ... want to consider the user-managed containers as their emulations of the server Container interface, but entirely not our problem
09:23:32 <pchampin> rui: could be useful, but that's different from my question
09:24:16 <pchampin> ericP: in LDP, contains is server managed (you POST to a container, it contains the resource)
09:24:59 <pchampin> ... we can allow to emulate our container model in userland
09:25:36 <pchampin> ... rather then defining complicated things such as "hierarchies"
09:26:05 <ericP> s/complicated things such as "hierarchies"/complicated things such as polyhierarchies/
09:26:17 <ericP> scribe+
09:27:29 <ericP> pchampin: we assume that the server manages the presence in a container but we could decouple that from @@99
09:27:56 <ericP> scribe-
09:28:09 <pchampin> s/@@99/the side effect that the server *has* to deal with (regarding ACL)
09:28:49 <pchampin> RRSAgent, make minutes
09:28:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/09-lws-minutes.html pchampin
09:28:57 <pchampin> present+
09:29:43 <pchampin> present+ bartb
09:30:03 <pchampin> present+ aaron
09:30:10 <pchampin> RRSAgent, make minutes
09:30:11 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/09-lws-minutes.html pchampin
09:30:28 <acoburn> acoburn has joined #lws
09:30:36 <acoburn> present+
09:30:41 <pchampin> s/sutopic:/subtopic:
09:30:43 <pchampin> RRSAgent, make minutes
09:30:44 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/09-lws-minutes.html pchampin
09:30:54 <ryey>  s/rui: /ryey: /
09:35:28 <acoburn> acoburn has joined #lws
09:38:50 <pchampin> present- aaron
09:38:52 <pchampin> RRSAgent, make minutes
09:38:54 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/09-lws-minutes.html pchampin
09:39:20 <bendm> scribe+ bendm
09:39:22 <pchampin> s/rui: /s:ryey: /g
09:39:24 <pchampin> scribe-
09:41:12 <bendm> acoburn: (writing Authorization Server and Resource Server/AS and RS on the white board)
09:41:32 <bendm> ... (and Relying Party/RP)
09:42:27 <bendm> ... I'm not suggesting OAuth2 is the only framework we should use
09:42:34 <bendm> ... but it gives us an abstract model to think about it
09:42:45 <bendm> ... so it should at least work with this
09:42:52 <pchampin>  i|laurens: we will start|scribe+ pchampin
09:42:54 <bendm> ... for SAML, the names are different, but the structure is the same
09:43:28 <bendm> ... at the very least, we need to describe the interface RS/AS and RS/RP
09:43:42 <bendm> ... question is: to what extent do we describe the other interactions?
09:44:22 <bendm> bendm: do we expect to support one authz protocol?
09:44:40 <bendm> acoburn: personal feeling: authz protocols keep changing
09:45:00 <bendm> ... OAuth2 and SAML are around for a long time, but there's OIDC/GNAP/... thinks keep changing
09:45:27 <bendm> ... being too rigid would hurt us
09:45:40 <bendm> laurens: but OAuth2 will probably not go anywhere soon
09:46:27 <bendm> acoburn: pinning to OAuth2 isn't too bad, but being too open brings complexity
09:47:22 <bendm> laurens: I've seen OAuth2 in very performant systems, and a lot of caching or optimizations is possible
09:47:30 <bendm> acoburn: also, this is an abstract model
09:47:42 <bendm> pchampin: can we go through the responsibilities?
09:47:47 <bendm> acoburn: generally speaking:
09:47:58 <bendm> ... simplest case:
09:48:16 <bendm> ... 1 app (RP), 1 RS, 1 known AS
09:48:49 <bendm> ... RP: if no token, do request to AS (client credentials, via browser or backend), get token
09:49:46 <bendm> ... token is sent from RP to RS (JWT or something else), RS validates token (token introspection via roundtrip from AS, or via key material from AS without roundtrip)
09:50:15 <bendm> ... RP is an application, client,...
09:50:39 <bendm> ... the thing that is trying to do the GET/...
09:51:07 <bendm> ... 1st problem: how to find the AS? you go to the RS first
09:51:35 <bendm> ... you get a 401 with WWW-AUTHENTICATE header that hints to the AS
09:52:15 <bendm> ... could just be 'Bearer', meaning 'just fetch it at the AS, you know where it is'
09:52:36 <bendm> ... given we're decentralized, we probably we want 'Bearer; <as_uri>'
09:52:48 <bendm> ... we can do this without requiring UMA
09:53:49 <bendm> ... this is on the HTTP level
09:54:14 <bendm> ... scheme and series of properties
09:54:22 <bendm> ... I'm pretty sure GNAP uses the same thing
09:55:03 <bendm> laurens: yes, there's a convention
09:55:32 <bendm> acoburn: if it was UMA: it would include a ticket and state 'UMA' instead of 'Bearer'
09:56:02 <bendm> ... basically what is stated is 'follow the semantic of the scheme that is presented', ie Bearer, UMA, GNAP
09:56:45 <bendm> ... I don't think we need to specify one
09:57:05 <bendm> ... but if we must (eg for testing), I would go for OAuth2
09:58:59 <bendm> ... there might be more steps between RS and AS, eg OIDC provider
09:59:15 <bendm> laurens: token exchange is a good fit for some problems we might have, RDF8693
09:59:20 <laurens> https://datatracker.ietf.org/doc/html/rfc8693
09:59:26 <bendm> ... RFC8693
10:00:15 <bendm> acoburn: with self-souvereign, the RP merges with _some_ of these intermediate steps between RP and AS
10:00:49 <bendm> ... so there will always be some kind of distinction between the AS and the RS
10:01:20 <bendm> ... and always some kind of distinction between RP and RS, even if deployed on the same server
10:02:22 <laurens> laurens has joined #lws
10:02:57 <bendm> acoburn: RP could have done some authn beforehand, but that's not necessary
10:03:16 <bendm> ... an RS could have different authz setups
10:03:45 <bendm> laurens: Solid uses an OIDC ID token, so it's cleaner to have a distinct authz server
10:03:57 <bendm> ... also for token lifetimes etc
10:04:10 <bendm> ryey: so there's no consdering of exposing sensitive info?
10:04:19 <bendm> acoburn: so far, everything is public
10:04:41 <bendm> ... any token _should_ be opaque, but it's often a signed JWT etc
10:04:58 <bendm> ... so what kind of info that goes into that JWT needs to be considered
10:05:37 <bendm> ... simple model is that we define the RS, and the interaction boundaries between RP and AS, and that's it
10:05:51 <bendm> ... more complex is that we also include all interactions between RP and AS
10:06:01 <bendm> ... eg if you do it like X, you must do it like <ref>
10:07:24 <bendm> laurens: I see a lot of complexity when dynamically being able to manage AS
10:08:08 <bendm> ... AS signifies the protocol, not implies anything about the policies used
10:08:46 <bendm> ... AS check whether you have the right authn and credentials
10:08:53 <bendm> bendm: but then who does the authz?
10:09:00 <bendm> acoburn: there's different models
10:09:28 <bendm> ... to be defined: the token sent by the AS: how does that look like?
10:10:05 <bendm> ... first define the data model of that token
10:10:25 <bendm> laurens: I suggest splitting course-grained authz via the AS with fine-grained authz via the RS
10:10:36 <bendm> acoburn: model 1: token contains a yes or no
10:11:10 <bendm> ... model 2: token contains a partial decision, and the RS roundtrips to the AS for the fine-grained decision
10:11:29 <bendm> ... historically, model 1 was used (eg via scopes)
10:12:05 <bendm> ... i.e. you have scope read:X, RS says 'write:X is not allowed'
10:12:38 <bendm> ... justin richter from GNAP has lots of experience why scopes are not sufficient
10:12:49 <bendm> laurens: currently, scopes are defined by the RS
10:13:06 <bendm> acoburn: yes, and tend to be very app-specific, thus not interoperable
10:13:29 <bendm> laurens: so ACL rules with has:scope would be horrible for interop
10:14:05 <bendm> ... example: you have a public resource
10:14:16 <bendm> ... you don't get an AS redirect
10:14:47 <bendm> ... for a private resource: you get a token via AS that _might_ give you access
10:14:59 <bendm> ... RS is tasked with the decision: can you do XYZ?
10:15:29 <bendm> ... the RP gets the response of the RS whether the action is succesful
10:16:21 <bendm> ... part of the decision could be via the AS, but the RS is in control
10:16:29 <bendm> bendm: that feels like bad separation of concerns?
10:16:43 <bendm> laurens: let's say you have A and B, you have access to A
10:16:53 <acoburn> acoburn has joined #lws
10:17:11 <bendm> ... you want A, you go via AS, and get a token for A
10:17:18 <bendm> ... you cannot reuse that for B
10:18:15 <bendm> ... also, AS, doesn't know what type of operation you want to perform
10:19:08 <bendm> bendm: but then, you can't solve that with scopes?
10:20:00 <bendm> laurens: this has been a long-standing issue, RFC9396 is a solution to that: rich authz request
10:20:47 <bendm> acoburn: JWT has a couple of claims (headers, sub, iss, and aud)
10:21:04 <bendm> ... RDF9396 suggests additional claim 'authz details'
10:22:25 <bendm> ... adds locations/actions/privileges/datatypes
10:22:54 <bendm> ... this gets sent to the AS to check whether you can do all of this
10:23:03 <bendm> ... and gets mirrored back to the JWT
10:24:01 <bendm> bendm: so basically, this is an alternative to more specialized/formalized scopes
10:24:10 <bendm> laurens: this allows the RS to fully know what to do
10:24:19 <bendm> ... ie. say yes or no to specific requests
10:26:00 <bendm> ... you can have an array of authz details
10:27:11 <bendm> ryey: do you need to specify these datatypes details?
10:27:12 <bendm> laurens: no
10:28:03 <bendm> ... for LWS, we could specify for actions the modes we allow in the authorization model
10:28:36 <bendm> pchampin: so, once authenticated, this can happen under the hood, without me noticing?
10:29:00 <bendm> acoburn: this is specifically for the RP talking to the RS what they want
10:29:32 <bendm> pchampin: so, we are constraining the connections between RP and AS?
10:30:05 <bendm> acoburn: we mostly want to give guidance: RP and AS interactions keep changes
10:30:35 <bendm> ericP: RP/AS links change more frequently than the other links?
10:30:51 <bendm> acoburn: historically, RP/RS link is entirely app-defined
10:31:16 <bendm> ... first step is to create an abstract model for what that looks like
10:31:44 <bendm> ... to get interop foor OAuth and JWT, wichi is the majority of things that work
10:34:12 <bendm> bendm: so maybe first next topic is to see how we can align this with current status quo?
11:26:18 <gibsonf1> gibsonf1 has joined #lws
11:37:07 <acoburn> acoburn has joined #lws
11:44:09 <bendm> bendm has joined #lws
11:45:55 <laurens> laurens has joined #lws
11:46:05 <laurens> rssagent, draft minutes
11:46:05 <pchampin> scribe+
11:46:15 <pchampin> [we reconvene after lunch]
11:46:25 <laurens> rrsagent, draft minutes
11:46:27 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/09-lws-minutes.html laurens
11:47:12 <ryey> ryey has joined #lws
11:47:30 <pchampin> acoburn: to recap, the Relying Party (RP) asks for a resource to the Resource Server (RS), and gets a 401 with a link to the Authorisation Server (AS)
11:47:52 <pchampin> ... that requires the RS to be aware of the AS  (RS-AS interface in the diagram)
11:48:40 <pchampin> ... another aspect of the RS-AS interface is whether the AS has access to the policies on the RS (the 'acl' resource)
11:48:52 <pchampin> laurens: I think it should have access
11:49:06 <pchampin> acoburn: depends on the path we are taking
11:49:36 <pchampin> ... the policy might be hosted on the AS, or at least in a location that is aware of the AS
11:50:07 <pchampin> laurens: either it is going to be on the RS as a regular RDF resource, or a specific resource managed by the AS
11:50:28 <pchampin> acoburn: ESS does the latter; both models could work, with pros and cons
11:50:38 <pchampin> laurens: I would not mandate one or the other in the spec
11:51:08 <pchampin> ben: I don't think that the RS needs to know what is in the policy
11:51:47 <pchampin> laurens: it does not need it in the model we are discussing; in the current model of Solid, this is different
11:52:09 <pchampin> ... in the current Solid model, the RS makes the final decision about authorization
11:52:38 <pchampin> pchampin: by "current Solid model", you mean...
11:52:47 <pchampin> laurens: ... Solid with Solid OIDC
11:53:38 <pchampin> ... the only thing that the RS has to make the decision is the identity of the user
11:54:07 <pchampin> ... I think we want to cleanup the separation of concerns
11:54:34 <pchampin> ben: with this separation the Policy language is not anymore in scope of the spec
11:54:51 <pchampin> acoburn: this is tricky, because this would kill interop when it comes to manage policies
11:55:31 <pchampin> ... on the other hand, I have low confidence in WAC or ACP being long term solutions for LWS
11:55:54 <pchampin> ... but that's all we have today, so I would like to make do with what we have, but leave the door open for other policy languages in the future
11:56:20 <pchampin> laurens: to play the devil's advocate: we don't need the policy language to be the interface to policy management
11:56:49 <pchampin> ... we could define an interface to request/grant/revoke access
11:57:13 <pchampin> ... it is a big step from the current state
11:57:45 <pchampin> acoburn: this would be a middle ground
11:58:27 <pchampin> ... this amounts to ask "can you answer these questions" (fields in "Authorization details")
11:58:43 <ryey> RSSAgent, make minutes
11:58:44 <wonsuk> wonsuk has joined #lws
11:58:45 <pchampin> laurens: this is a form of discretionary access control
11:59:18 <pchampin> ... role-based access control @@
11:59:29 <pchampin> ... attribute-based access control is yet something entirely different
11:59:39 <ryey> s/RSSAgent/RRSAgent/
12:00:17 <pchampin> ben: WAC maps an identity to the different operations; ACP maps a VC to the different operations
12:00:36 <pchampin> s/@@/would be more general
12:00:51 <ryey> RRSAgent, make minutues
12:00:51 <RRSAgent> I'm logging. I don't understand 'make minutues', ryey.  Try /msg RRSAgent help
12:01:07 <pchampin> acoburn: in JWT, sub is the agent (as a person)
12:01:20 <pchampin> ... iss is the issuer
12:01:31 <pchampin> ... aud (audience) is your app, the Relying Party
12:01:45 <ryey> RRSAgent, make minutes
12:01:46 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/09-lws-minutes.html ryey
12:01:55 <pchampin> ... actually, there are two ways of defining "audience". It is "the entity to which you are sending the token"
12:02:04 <pchampin> ... different based on your PoV
12:02:51 <pchampin> laurens: I don't think that aud is always the RP in OAuth
12:03:04 <pchampin> acoburn: aud can be a single value or an array
12:03:19 <pchampin> ... if you want it to be the RP and the RS, you would put both
12:03:40 <pchampin> ... there is also "authorized party" (azp), which would be the client; it needs to be in aud
12:05:11 <pchampin> s|[we reconvene after lunch]|[we reconvene after lunch, gibsonf1 joins]
12:05:23 <pchampin> present+ gibsonf1
12:06:20 <pchampin> [discussion on the respective role of the JWS claims in OAuth]
12:07:04 <pchampin> acoburn: we could say the 'aud' must contain both the RP and RS, and that 'azp' must be 'RP'
12:07:24 <pchampin> ... arguably this is most complete, and less subject to interpretation
12:07:33 <pchampin> ben: who is expected to generates that?
12:08:14 <pchampin> acoburn: the AS. You could use any AS you want, but it must produce a JWT that satisfies these constraints.
12:09:08 <pchampin> ... the most complicated thing we have to do right now is to define the structure of the token sent from RP to RS.
12:10:50 <pchampin> laurens: one problem with Solid today is that we are relying on OpenID Connect providers, who act both as Authentication and Authorization servers
12:11:33 <pchampin> ... we reuse the identity token as an auhtorization token
12:12:31 <pchampin> ... with Token-Exchange, we could define how to exchange the identity token for a complying access  token, scoped to the operations you want to perform
12:13:09 <pchampin> ... the most common use-case is backend for frontend
12:13:38 <pchampin> ... the backend is taking the identity token from the user to get an access token for itself, limiting security risks
12:14:29 <pchampin> acoburn: some people in the DPop world consider it an anti-pattern to associate a DPop key with an identity token, and they are not wrong
12:14:44 <pchampin> ... currently, identity tokens in Solid are very powerful, could be reused in a malicious way
12:15:02 <pchampin> ... by requiring this exchange of token, the security scope becomes much more narrow
12:15:51 <pchampin> laurens: suppose you have a malicious Solid server, it gets an ID token; it can be reused with any other server you have access to
12:16:15 <pchampin> ... mechanisms like Token-Exchange allow you to prevent that
12:17:14 <pchampin> acoburn: the trick is that it is the application that the user uses that does the token exchange to scope it
12:17:31 <pchampin> gibsonf1: the way we do it is to restrict the token to the user AND the application
12:17:38 <pchampin> ... so the server can not reuse it as such
12:17:58 <pchampin> laurens: this addresses impersonation, but not the replay attack
12:18:42 <pchampin> bendm: does the RP not know where the request come from?
12:18:48 <pchampin> acoburn: no
12:19:40 <pchampin> laurens: in the authorization problem, we need to assume the token can come from anywhere
12:20:36 <pchampin> acoburn: the RP starts with the ID token, but it will never send it to the RS
12:20:48 <pchampin> ... (although that's what is happening right now)
12:21:46 <pchampin> ryey: if we are considering malicious RS, shouldn't we also consider malicious AS?
12:21:53 <pchampin> laurens: we should indeed.
12:22:16 <pchampin> ... If you have an ID token, it will be bound to the POST operation on the AS.
12:22:45 <pchampin> ... The malicious AS server can not replay this ID token on another AS  server.
12:22:54 <pchampin> ... At least that's the threat model of Dpop.
12:23:36 <pchampin> ... Still, the problem with ID token is that they contain many claims about the identity of the user, and they are not properly restricted to the target audience.
12:24:58 <pchampin> acoburn: ryey, you were talking a malicious RS sending a legitimate RP to a malicious AS
12:25:02 <pchampin> ... that's a real problem
12:25:17 <pchampin> ... the way I would mitigate that: rather than sending the ID token directly to the AS,
12:25:37 <pchampin> ... the user controlling has a set of trusted token exchange servers
12:25:37 <bendm> q+ to ask about scope between interactions AS/RP, why not trust the AS?
12:26:11 <pchampin> ... you exchange your ID token with this trusted server for a more restricted access server, that you then send to the AS
12:26:54 <pchampin> ... this protects the user even if the RS-AP pair is malicious
12:28:01 <pchampin> ... in this first exchange, the iss would be your token exchange server, the aud would be the AS you have been sent to
12:28:15 <pchampin> ... so it can not be reused anywhere
12:28:27 <pchampin> ack bendm
12:28:27 <Zakim> bendm, you wanted to ask about scope between interactions AS/RP, why not trust the AS?
12:28:52 <pchampin> bendm: is it necessary to do it like this in every use case?
12:29:01 <pchampin> ... if I trust the AS, can I skip the first step?
12:29:24 <pchampin> laurens: I'm assuming that the RP is not the owner of the RS.
12:29:43 <pchampin> ... In the case of the Flemish government, they are one and the same, so it is a simple case.
12:30:38 <pchampin> acoburn: in the use-cases we have addressed at Inrupt, it was more a federation than a distributed system
12:30:59 <pchampin> ... so the notion of malicious AS is moot in this context
12:31:28 <pchampin> ... there are cases where, even in a Federation, you would require this first token-exchange
12:31:37 <pchampin> ... I would make it possible but not mandatory
12:32:07 <pchampin> bendm: do we really need to describe these different levels of complexity?
12:32:28 <pchampin> ... what part of it is in our scope? should this be just a note?
12:32:53 <pchampin> acoburn: in my opinion, it is all out of scope, but we need to consider it.
12:33:13 <pchampin> ... It would be material for a primer, a best-practices document, but out-of-scope for the protocol document.
12:33:27 <pchampin> laurens: I tend to disagree.
12:33:52 <pchampin> ... the AS may provide you with a token-exchange grant, and if they do, the semantics needs to be defined
12:34:00 <pchampin> ... otherwise, this is a hindrance to interop.
12:34:50 <pchampin> acoburn: I don't think we want to require anything about token-exchange,
12:35:04 <pchampin> ... but I would agree that some document somewhere should explain:
12:35:13 <pchampin> ... "if you are to use token-exchange, this is what you need to do"
12:35:30 <pchampin> laurens: if you are to implement an LWS client that is authenticated,
12:35:38 <pchampin> ... what do you need to provide?
12:35:51 <pchampin> acoburn: how do you build interoperable clients? that's fair
12:36:35 <pchampin> laurens: currently, Solid OIDC is very simple (with security implications)
12:37:39 <pchampin> acoburn: in my mental model: you can configure your client to use a proxy server, without the client's developer being aware
12:37:44 <pchampin> ... in a way this is similar here
12:38:15 <pchampin> ... all the token-exchange part can be configured independently of the client
12:38:42 <pchampin> ... but I agree that we need to describe it somewhere
12:39:10 <pchampin> ericP: we need to specify how a client that can do token-exchange knows where and how to use it
12:40:34 <pchampin> laurens: what we have right now is an ill-designed solution
12:41:02 <pchampin> ... what we should avoid doing is throwing everything out of scope, and leave it to the implementers to discover what to use
12:41:18 <pchampin> ... we should strive for interoperable ecosystems
12:41:29 <pchampin> ... token-exchange is just one way to solve this problem
12:42:05 <pchampin> ... yes, we need to afford for evolutions, but we should not leave it entirely unspecified
12:42:45 <pchampin> bendm: I think what you are saying is that we must specify the RP-AS interaction, which I understood was out-of-scope
12:42:56 <pchampin> laurens: I don't think we have consensus that it is out-of-scope
12:43:06 <pchampin> ... the current Solid spec somehow specifies that
12:44:30 <pchampin> ... if we don't specify that part, different community will chose different non-interoperable solutions
12:44:50 <pchampin> ... we need some normative description of that part, maybe reusing an existing one
12:45:26 <pchampin> acoburn: I think we could define in abstract terms: "you need to provide a credential in some form, that contains this information: ..."
12:45:59 <pchampin> laurens: we are probably going to specify the identifiers of RP, and restrict the interactions between RP and AS
12:46:59 <pchampin> ... the interaction between RP and AS is essentially about authentication
12:47:16 <pchampin> acoburn: maybe we should switch the discussion to authentication, then
12:48:05 <pchampin> ... jeswr and I discussed during lunch, I would like to volunteer to make some proposal about what is needed here
12:48:13 <pchampin> ... I would like to volunteer Dmitri as well
12:48:50 <pchampin> laurens: there are several levels to which we could specify authorization
12:49:11 <pchampin> ... but specifying a policy language is probably scope for a WG in and of its own
12:49:18 <pchampin> acoburn: we have 6 months
12:49:29 <pchampin> ... I think it is out of the question to invent something new
12:49:41 <pchampin> ... I think it is out of the question to hack an existing solution to our needs
12:49:56 <pchampin> ... we can abstractly describe what we need, allowing future specifications to be used
12:50:23 <pchampin> laurens: I think defining an API for requesting/granting/revoking access is something we *can* do
12:50:42 <pchampin> ... it means a deviation from what we have in Solid right now
12:50:55 <pchampin> acoburn: there are different ways of scoping this
12:51:24 <pchampin> ... one way is to specify the "box" that stands bewteen RP and AS. I think this is doable.
12:51:36 <pchampin> ... and it may be swapable in the future
12:51:47 <pchampin> laurens: we could even reuse something existing here
12:52:48 <pchampin> pchampin: I think the decoupling mentioned in our charter puts all 3 edges in scope
12:52:58 <pchampin> jeswr: I'm supporting of that
12:53:19 <pchampin> ... I think the LWS spec should speak abstractly of the policy graph
12:53:42 <pchampin> acoburn: there is prior art for access request (SAI, the interop group, Inrupt's implementation)
12:54:11 <pchampin> laurens: there is also something that the Verifiable Credential people are doing
12:54:26 <pchampin> ... OpenID4VP
12:54:55 <pchampin> jeswr: does OpenID4VP involve an access request?
12:55:04 <pchampin> laurens: the Presentation Request is similar
12:55:37 <pchampin> jeswr: my understanding of OpenID4VP is that it is a closed flow; it does not allow for a user to intervene to consent to grant access
12:56:11 <pchampin> laurens: agreed; asynchronous access grant is something that OpenID wants to solve, and there are potential solutions to that, but that's complicated
12:56:22 <pchampin> bendm: do we also want to solve that?
12:56:55 <pchampin> laurens: they have similar use-cases to ours?
12:57:09 <pchampin> bendm: do we not run the risk of designing a competing solution, then?
12:57:58 <laurens5> laurens5 has joined #lws
12:57:58 <pchampin> laurens: they are also referring to 'Authorization details', we might try to solve some of these problems together, but as we have the same timeline, that may not be practical
12:58:02 <laurens5> https://openid.net/new-whitepaper-tackles-ai-agent-identity-challenges/
12:58:24 <pchampin> bendm: should we spend the 6 months left solving something that others will solve in 1y?
12:58:39 <pchampin> ericP: do we have reasons to believe that our use-cases are unique?
12:59:00 <pchampin> laurens: I believe that we are looking at more affordances than they do.
12:59:30 <pchampin> jeswr: my naive hypothesis is that the pre-conditions around authorizations are going to be the same, but the effects might differ.
13:00:13 <pchampin> laurens: "me giving access to you to a resource on my storage" is not something they are trying to solve
13:00:55 <pchampin> ... their use-case is "me giving access to an agent to some service over which I have some control"
13:01:13 <pchampin> s/me giving access to you to a resource on my storage/me requesting access to a resource you control/
13:02:39 <pchampin> bendm: we need to build something that is swapable
13:03:23 <pchampin> laurens: any protocol we define should be made in a generic way, with a concrete binding to a specific technology, similar to what we do for operations
13:04:41 <pchampin> bendm: do I understand correctly: I have my pod with my AS, and I give you access; how do we ensure that your client can interact with my AS
13:05:54 <pchampin> laurens describes some affordances in OAuth
13:06:15 <pchampin> laurens: what we want to avoid is each AS implementation inventing their own scheme
13:06:24 <pchampin> bendm: but we have existing schemes
13:06:32 <pchampin> laurens: yes but they are very generic
13:07:45 <pchampin> ... e.g. token-exchange is one specific grant of OAuth, and requires more specification to be useful
13:08:42 <pchampin> s/OAuth/OAuth2
13:09:06 <pchampin> ... it is not part of core OAuth2, so you need to specify "use OAuth2 + token-echange in this specific way"
13:10:11 <ryey> q+ (to say after break) 1) no interaction between RS and AS ???; 2) we are too abstract yet and hard to persuade from either side; why don't we start from use cases, and see how they are supported by each mechanism?
13:10:54 <ryey> s/q+ (to say after break)/q+ to say after break:/
13:13:42 <pchampin> photo of the flipchart: https://www.w3.org/2025/10/09-lws-photo1.jpg
13:13:48 <pchampin> RRSAgent, make minutes
13:13:49 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/09-lws-minutes.html pchampin
13:14:37 <pchampin> i|writing Authorization Server and Resource|topic: Authorization
13:14:46 <pchampin> RRSAgent, make minutes
13:14:47 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/09-lws-minutes.html pchampin
13:16:15 <bendm> scribe+
13:21:28 <bendm> laurens: let's talk about Auth
13:21:47 <pchampin> i|let's talk about Auth|topic: Authentication
13:22:19 <bendm> ryey: shouldn't we talk about interaction patterns between entities? which support which use cases?
13:22:37 <bendm> acoburn: client-server / server-server: diversity is in authn
13:22:46 <bendm> ... everything else ends up being the same
13:23:09 <bendm>  ryey: that probably won't work for all cases, being either too flexible or too complicated
13:23:18 <bendm> laurens: 2 situations
13:23:56 <bendm> ... 1: user A using client A, client A interacts with RS A and AS A
13:24:02 <bendm> ... typical for Solid
13:24:31 <bendm> user A has WebID, client A is non-confidential (runs in userspace: it cannot keep a secret from the user)
13:24:48 <bendm> laurens: (said before line)
13:25:14 <bendm> ... client A interacts with IdP A, user A gives, e.g. username/password via the client A
13:25:23 <bendm> ... client is authenticated on its behalf
13:25:36 <bendm> ... client probably needs to interact with AS A, on behalf of user A
13:26:02 <bendm> ... as client A cannot have secrets from user A, it needs things like DPoP
13:26:28 <bendm> ... sitaution 2: confidential client: has its own identity, can keep secrets from users
13:26:44 <ericP> ericP has joined #lws
13:26:47 <bendm> ... i.e. identities are decoupled
13:27:03 <bendm> ... for situation 2, we currently need to hack around
13:27:43 <bendm> ... we could do something with its own confidential client (let's call it client B) with its own oidc token, but that's out of solid's spec
13:28:17 <bendm> ... we need some generic things to make sure both situations are possible, in LWS
13:28:34 <bendm> acoburn: in OIDC, (either explicit or implied everywhere), OIDC is for browsers
13:28:42 <bendm> ... that's what it's built for
13:28:57 <bendm> laurens: and they refer to OAuth to do that
13:29:10 <bendm> ... and mostly non-normative language I think
13:29:31 <pchampin> scribe+
13:30:04 <bendm> laurens: we can have 2 flows for 2 situations
13:30:12 <bendm> ... non-confidential and confidential clients
13:30:21 <pchampin> i|we can have|bendm: is it naive to suggest that we have two situations, so we should have two flows?
13:30:26 <pchampin> scribe-
13:30:29 <bendm> ... the scenarios need to be treated separately
13:31:22 <bendm> ... you can imagine some kind of controlled identifier documents for confidential clients
13:31:32 <bendm> ... for non-confidential clients, OIDC should be fine
13:32:13 <bendm> ryey: what about, e.g. delegated actions (client A asking client B to do something?)
13:32:28 <bendm> laurens: I would not specify anything between clients
13:32:36 <bendm> acoburn: that could be built on top of LWS
13:33:05 <bendm> ryey: but, it will be hard then to support combinated scenarios
13:33:12 <bendm> ... eg the knoodle case
13:33:46 <bendm> ... there's a web-based client, and a service, user interacts mostly with client, but sometimes the service needs to work independently
13:34:24 <bendm> laurens: I think you are talking about a resource service
13:34:57 <bendm> ... that will probably have its own resource server
13:35:40 <bendm> ... what will not specified is 2 client applications that can arbitrarily start doing services without being chosen by the controller or storage provider
13:35:58 <bendm> q+ to talk about services
13:36:18 <bendm> jeswr: so I'm think about a server needing to ask something to the resource server
13:36:38 <bendm> ... so a client application that has a server component
13:36:45 <bendm> ... in that case, I would expect that's the same client
13:37:19 <bendm> laurens: services over storage are either something chosen by the storage provider, or by the controller
13:37:59 <bendm> acoburn: talking about client-to-client, in a sense, it's client-to-server, but then in 2 parts: same entity, but actually doing client-to-client service-to-storage
13:38:08 <bendm> ... so maybe it's rather delegation?
13:38:24 <bendm> ... i.e. that could be via a refresh token (if it's delegation)
13:38:31 <bendm> ... or a service that works on its own behalf
13:38:48 <bendm> ... in the latter case, it's a confidential client
13:39:24 <bendm> ryey: OK, just wanted to understand whether the model makes that possible
13:39:37 <bendm> laurens: now we come into impersonation and delegation
13:39:54 <bendm> ... currently, Solid is mostly allowing impersonation
13:40:17 <bendm> ... i.e. via WAC
13:40:35 <bendm> q-
13:40:42 <bendm> laurens: talking about delegation
13:41:01 <bendm> ... OAuth token exchange is well positioned for delegation
13:41:13 <bendm> ... it keeps the provenance during token exchange
13:41:28 <bendm> acoburn: token exchange RDF has a very good section on impersonation vs delegation
13:41:39 <pchampin> ack bendm
13:42:00 <pchampin> bendm: I understand the usefulness of delegation. Is this something that we want to force on all LWS implementations as a MUST?
13:42:20 <bendm> acoburn: we don't need to force it, but we need to describe how it would work
13:42:30 <bendm> laurens: you should be able to do delegation if you want
13:42:47 <bendm> ... delegation will likely be the best option
13:42:58 <bendm> ... impersonation, only thing you can do is pod browser
13:43:08 <bendm> ... for more restricted application, you run into problems
13:43:25 <bendm> ... for which you need ACP or access request/grant in ESS
13:43:55 <bendm> pchampin: does that mean that fine-grained access requires a confidential client?
13:44:00 <bendm> laurens: I think no
13:44:43 <bendm> ... the main distinction (which token exchange does really well): an actor claim that gives the full actor chain during exchange
13:45:10 <bendm> ... so provenance/delegation chain you can follow
13:45:45 <bendm> ... good for frontend+backend for frontend and proxy, for example
13:46:35 <pchampin> bendm: beating a dead horse: I want to still be able to deploy a simple solution
13:47:06 <bendm> laurens: I would want the authz server to clarify that the user might want to do something dangerous
13:47:11 <pchampin> laurens: as long as the user is notified that they are doing something dangerous
13:47:20 <bendm> acoburn: azp claim (ie identity of the client)
13:47:24 <pchampin> s|laurens: as long as the user is notified that they are doing something dangerous|
13:48:25 <bendm> ... for non-confidential client: solid-OIDC specifies how to get an identity token
13:48:35 <bendm> ... for confidential client: no specification currently exists
13:48:38 <bendm> ... and it should
13:48:48 <pchampin> +1
13:48:53 <bendm> laurens: another problem is dynamic client discovery
13:49:16 <bendm> ... eg using keycloak: you need to do static client registration
13:49:26 <bendm> ... manually creating client id and secret
13:49:36 <bendm> ... that's a typical flow
13:50:15 <bendm> ... dynamic client registration (ie. client is RP): IdP might have never heard of that RP
13:50:55 <bendm> acoburn: dynamic client registration used to be the only way in Solid to bootstrap client flow
13:51:12 <bendm> laurens: authz needs to know where the user should be redirected to
13:51:55 <bendm> ... PCKE prevents replay attacks
13:52:24 <bendm> ... client id documents is another way to solve that
13:53:02 <bendm> acoburn: dynamic client registration: you don't have an identity for your RP, it's the same as an anonymous IdP/it's ephemeral
13:53:22 <bendm> ... i.e. you cannot distinguish 2 dynamically registered clients
13:54:00 <bendm> ... my position: we should not use dynamic client registration
13:54:24 <bendm> laurens: +1, also, we need something for confidential clients
13:54:44 <pchampin> s/PCKE/PKCE
13:55:00 <bendm> jeswr: if we don't have dynamic registration, does that mean we always need a client header or something?
13:55:11 <bendm> acoburn: an allow list is unusable
13:55:58 <bendm> jeswr: so, as an application implementer, I don't need to ask an idp to be added?
13:56:22 <bendm> laurens: each app registering themselves at all IdPs is not scalable
13:57:01 <bendm> ... we do need affordance to advertise the right attributes in a describing document (ie to be verifiable, what we do with client id documents)
13:57:17 <bendm> acoburn: let's start with confidential clients, they're easier to solve
13:59:32 <bendm> ... requirement: I want to give access for certain types of data to certain types of applications, then dynamic client registration doesn't solve this
14:00:04 <bendm> acoburn: confidential clients
14:00:15 <dmitriz> dmitriz has joined #lws
14:01:50 <bendm> ... JWT: sub = iss
14:02:01 <pchampin> bendm: is it the way you propose it? the way it is done in prior art?
14:02:07 <bendm> laurens: this is different from client credentials
14:02:34 <bendm> ... client credentials rely on external authz
14:02:41 <bendm> ... server (AS)
14:03:17 <bendm> acoburn: conf client: either delegates to external identity provider, or stores the secret itself
14:03:42 <bendm> ... question is: who has the private key material?
14:04:01 <bendm> ... client credentials flow: you ask the IdP to give you a JWT, then iss and sub claims will be different
14:04:22 <bendm> ... other idea is that the client has its own private key, then iss and sub are the same
14:04:49 <bendm> laurens: you can base this on the controlled identifier spec
14:05:22 <bendm> acoburn: and then the CID is the same as the sub/iss
14:05:37 <bendm> ... and there's a way of expressing a public JWT
14:06:09 <bendm> laurens: here, we assume that the client has control of the private key
14:06:18 <bendm> ... client will build the token itself
14:07:07 <bendm> laurens: this will be something that we will have to spec?
14:07:28 <bendm> acoburn: in this case, you want the audience to be the AS
14:08:16 <pchampin> bendm: couldn't the AS just be told to trust this client?
14:08:30 <bendm> acoburn: yes, that's what would be in the policy
14:08:53 <bendm> laurens: that's probably what we need to have a notification flow of
14:09:24 <bendm> acoburn: another part is the code grant, part of OAuth
14:09:27 <bendm> ... this is private key JWT
14:10:04 <bendm> ... there is an existing OAuth flow that describes this
14:10:11 <bendm> laurens: probably in the client assertion spec
14:11:13 <bendm> ... what we need to spec is the AS to resolve the CID, get the JWK, to validate the signed JWT
14:11:36 <bendm> ... eg the flemish gnmt also uses that JWT, but we have a service where clients need to register with a JWK
14:12:51 <pchampin> bendm: I assume there are many other ways to do this; this is just how we recommend to do it, right?
14:13:13 <bendm> laurens: I think you'll have 2 scenarios: an agent that refers to an IdP to assert they identity, and clients that self-assert their identity
14:13:31 <bendm> ... I think we need to support both
14:14:15 <bendm> acoburn: technically, in the headers, there's going to be a key ID (kid), whereas the CID is your subject. so the key material will be the subject + kid
14:14:26 <bendm> ... I think CID alreayd has that
14:14:49 <bendm> pchampin : CID is published with VC2
14:15:00 <bendm> ... it's a generalization of the DID document, and DID will depend on CID
14:15:18 <bendm> ... CID is about the document format, not how you resolve it
14:15:40 <bendm> laurens: we kind of ssume here that we know how to resolve a CID
14:15:59 <bendm> ... I desire to have at least one resolution mehod in the spec
14:16:37 <bendm> pchampin: in retrospect, DID adds on top of CID: a new type of identifier and a way how to resolve
14:18:03 <bendm> bendm: talking aoubt pseudonimity
14:18:48 <bendm> pchampin: so actually, you not really are talking about confidential and non-confidential client, but rather IdP-asserted and self-asserted clients?
14:19:21 <bendm> ... the CID could be an ephemeral DID
14:19:53 <bendm> laurens: in OIDC, you will always have a strong-asserted identity
14:20:49 <bendm> bendm: so you could have self-asserted identities, also in client-server sitautions
14:24:17 <bendm> laurens: what we have been doing now, is the interaction between the RP and the IdP
14:24:36 <bendm> ... and IdP is part of the OIDC-flows
14:25:13 <bendm> acoburn: in OAuth, they typically have an OP (OpenID Provider), which we call IdP, which can be separate from the AS
14:25:45 <bendm> ... and the category of confidential clients that have self-asserted identities do not have an IdP/OP
14:26:04 <bendm> laurens: for non-confidential clients, I assume the users of those clients also need to validate their identity
14:26:19 <bendm> pchampin: that's ucrrently the purpose of the WebID document?
14:26:40 <bendm> ... CID is a reduced WebID, without the profile information
14:26:57 <bendm> laurens: eg OpenID Provider could be a service in the user's CID
14:27:19 <bendm> acoburn: now we're talking about non-confidential clients
14:27:35 <bendm> ... how can we scope this so that it doesn't rely on non-spec things (such as WebID), but is still secure?
14:28:29 <bendm> ... sub = cid, iss = openid provider
14:28:51 <bendm> ... and OpenID Provider needs to be listed in the CID services
14:29:15 <bendm> laurens: this is really similar to the SolidOIDC
14:29:49 <bendm> acoburn: SolidOIDC has 3 features: the WebID scope results in a WebID claim
14:30:01 <bendm> ... we can use sub, being more aligned with everything else
14:30:35 <bendm> laurens: some AS are opinionated towards the sub
14:30:45 <bendm> ... opaque to the user but does identify it
14:31:04 <bendm> ... so that's not necessarily the same as using the (resolvable) CID
14:31:39 <bendm> acoburn: so some OpenID Providers put restrictions on the sub claim? so we might need to refer to a CID document in a different claim?
14:32:25 <bendm> laurens: yes, there might be some issues
14:32:32 <bendm> acoburn: what about the claim 'preferred username'?
14:32:38 <bendm> laurens: feels like overloading
14:32:48 <bendm> ... why was the webid claim introduced?
14:32:57 <bendm> acoburn: more historically?
14:33:32 <bendm> laurens: there has been a tendency for openID Providers to create new claims, rather than overloading existing ones
14:34:15 <bendm> ... it would be good to have the option of a fallback: first check a custom claim, and if not available, look at the subject
14:34:18 <bendm> acoburn: +1
14:34:26 <bendm> ... any suggestion for claim name?
14:35:14 <bendm> ... it's a web-based identity system... soooo... webid?
14:35:39 <bendm> pchamin: we could do controlled web identifier: cwid? pronounced seaweed
14:36:02 <bendm> acoburn: either in the JWT spec or OIDC specs, they talk about minting custom claims
14:36:27 <bendm> ... if you use a non-globally unique claim name (eg webid), you could register at iana
14:37:41 <bendm> ... or create a globally unique name, i.e. a URI for the claim key
14:37:44 <bendm> laurens: we could use the actor claim
14:37:56 <bendm> acoburn: we should doublecheck
14:38:14 <bendm> pchampin: but it still falls under the pitfall that we run the risk of overloading?
14:38:42 <bendm> ... I don't have strong opinions on URI vs IANA (we can do both)
14:38:57 <bendm> ... and I understand the issue of using a URI as a key in JSON
14:39:18 <bendm> acoburn: actor claim is used as a json object that has a sub claim
14:39:42 <bendm> laurens: if you have token delegation, then that initial subject claim is buried the deepest
14:41:36 <bendm> jeswr: does this mitigate the need for zcaps for delegated authority
14:41:48 <bendm> laurens: it's a way to express delegation chains in JWTs
14:41:53 <bendm> ... you still need a trust relation
14:42:07 <bendm> acoburn: zcaps themselves are typically not sent as bearer tokens
14:42:22 <bendm> ... so your processed token might not contain the full delegation chain
14:43:00 <bendm> laurens: prior actors are informational only... hmmm, so this might not actually work (you need to use the sub according to the spec)
14:43:52 <bendm> acoburn: let's have a placholder for now
14:44:22 <bendm> ... so, we have the fallback: first a specific claim (either a URI or an IANA registered name), if not available, try sub claim
14:44:40 <bendm> ... placeholder is called agent_id for now
14:45:35 <bendm> ... currently in solid, id tokens are directly sent to RSs
14:46:01 <bendm> ... in cases where ID tokens are not required to be directly sent to RSs or ASs, then the MUST for DPoP-bound ID tokens is no longer relevant
14:46:20 <bendm> ... you can still use DPoP to bind id tokens or access tokens
14:46:31 <bendm> laurens: if you can bind this token to a specific audience, ie the AS
14:46:35 <bendm> ... then yes
14:46:56 <bendm> ... but that audience claim is important (AS, or another token exchange service)
14:47:24 <bendm> acoburn: so we could say: if you're not able to perform token exchange, the audience claim should be scoped to the AS
14:48:02 <bendm> laurens: if you mandate that tokens are the proper AS/IdP token exchange, so removing the solid audience, you lose the requirement for DPoP
14:48:17 <bendm> ... what remains, is how non-confidential clients manage their key material
14:48:51 <bendm> ... so there are probably some security things to be considered
14:49:12 <bendm> acoburn: the last requirement of Solid-OIDC is client identifiers: that's the azp claim
14:49:32 <bendm> laurens: I don't think that OpenID has something
14:49:45 <bendm> acoburn: there's OpenID federation, but that's a lot of overhead
14:50:12 <bendm> ... there's Amelia and others who have taken the azp part as a separate spec, but I'm not sure about their timeline
14:50:40 <bendm> ... question is: how do you identify the client with strongly stable identifiers?
14:51:30 <bendm> ... the client id document is basically the info of dynamic client registration, this could be put/reformated in a CID
14:51:40 <bendm> laurens: I would have hoped there was a solution already
14:52:32 <bendm> acoburn: I would say: you should be using a strongly asserted global identification for the azp claim, this could be openid federation, but also could be client document
14:52:41 <bendm> laurens: static client registration systems should also be fine
14:53:13 <bendm> ... but I would want at least one spec'd
14:53:23 <bendm> acoburn: I'm not sure we need jsonld
14:53:49 <bendm> jeswr: I see use cases beyond authn.authz flows
14:54:09 <bendm> laurens: we could do jsonschema, with extensibility towards a context file
14:54:38 <bendm> jeswr: when we discussed containers, we discussed both jsonschema and context, I suggest, for consistency, to do the same here
14:54:43 <bendm> laurens: I'm not opposed to that
14:55:28 <bendm> ... what we need to talk about, cfr access requests and grants, for which we need client app identity
14:55:39 <bendm> acoburn: talking about topics/responsibilities
14:56:05 <bendm> ... I wanted to volunteer for the authz spec, specifically on the boundaries to the RS
14:56:22 <bendm> jeswr: I would like to pair
14:56:45 <bendm> ericP: I would also love to pair
14:56:56 <bendm> acoburn: regardless, there will be a lot of discussion
14:57:15 <bendm> ... I will lean a lot on Dmitri and Bango
14:57:21 <bendm> ... they will provide a lot of useful content
14:57:45 <bendm> laurens: how do split between Authn/Authz, and their facets?
14:58:10 <bendm> acoburn: I think: what are the inputs for the authz, maybe not defining specific formats, but the inputs
14:58:25 <bendm> ... one of these inputs could be 'a strongly asserted identity token'
14:58:41 <bendm> ... separately, we can define how that input looks like
14:58:52 <bendm> laurens: we could define some token types
14:59:02 <bendm> ... and we might need to specify some of the validation rules and structure
14:59:15 <bendm> acoburn: for authz, authn seems to be one of the inputs
14:59:28 <bendm> ... do we have a separate task for for authn, or is it one big bundle?
14:59:46 <bendm> ... (separate from the editing)
14:59:46 <bendm> ... we could have different specs
15:00:08 <bendm> laurens: input for the authz functions will be the start, so I suggest to start there
15:00:14 <bendm> ... and later define the gaps
15:01:24 <bendm> laurens: about the identity documents and client id documents
15:01:33 <bendm> ... are those separate, or are they relevant in the context of authn?
15:01:50 <bendm> acoburn: absent any better ideas, I suggest to define them in the context of authn
15:02:07 <bendm> ... I'm willing to work on authn as well
15:02:09 <bendm> laurens: me too
15:03:07 <pchampin> bendm: do we agree that other kinds of claim, like proving what your name is, are out of scope?
15:03:22 <bendm> laurens: up to now, we discussed discretionary access control: someone is given access to do certain access on certain resources
15:03:52 <bendm> ... it could be RBAC or ABAC, but that's out of scope of the specs
15:04:12 <bendm> ... if anyone feels that we would still need that, feel free to suggest anything
15:04:50 <bendm> acoburn: we don't prevent any implementation (existing or new) to adhere to this
15:05:04 <bendm> laurens: the spec is the subset of what we can agree on, the implementers can do fun new stuff on top of this
15:05:48 <laurens5> laurens5 has joined #lws
15:05:48 <wonsuk> wonsuk has joined #lws
15:05:48 <ryey> ryey has joined #lws
15:05:48 <laurens> laurens has joined #lws
15:05:48 <bendm> bendm has joined #lws
15:05:48 <gibsonf1> gibsonf1 has joined #lws
15:06:04 <bendm> acoburn: concerning timeframe: my availability is limited
15:07:04 <laurens5> laurens5 has joined #lws
15:07:04 <wonsuk> wonsuk has joined #lws
15:07:04 <ryey> ryey has joined #lws
15:07:04 <laurens> laurens has joined #lws
15:07:04 <bendm> bendm has joined #lws
15:07:04 <gibsonf1> gibsonf1 has joined #lws
15:07:12 <bendm> ... we'll be back tomorrow at 9:30
15:07:30 <bendm> ... dinner tonight at 7pm at Patrick Foleys