14:06:58 <RRSAgent> RRSAgent has joined #lws
14:07:02 <RRSAgent> logging to https://www.w3.org/2025/05/26-lws-irc
14:07:02 <Zakim> RRSAgent, make logs Public
14:07:03 <Zakim> please title this meeting ("meeting: ..."), pchampin
14:07:08 <pchampin> meeting: Linked Web Storage Working Group
14:07:27 <ericP> ericP has joined #lws
14:07:32 <ericP> present+
14:07:37 <pchampin> present+
14:07:44 <uvdsl> present+
14:07:50 <gibsonf1> present+
14:07:51 <Beau> present+
14:07:54 <RazaN> present+
14:08:05 <jeswr> jeswr has joined #lws
14:08:14 <jeswr> present+
14:08:18 <pchampin> agendabot, find agenda
14:08:18 <agendabot> pchampin, sorry, I don't know which mailing list or calendar is associated with this channel. Try "agendabot, help this is".
14:08:45 <pchampin> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250526T100000/#agenda
14:08:47 <agendabot> clear agenda
14:08:47 <agendabot> agenda+ Introductions and announcements
14:08:47 <agendabot> agenda+ Action Items
14:08:47 <agendabot> agenda+ Discussion: Authorization
14:08:47 <agendabot> agenda+ Use Cases status summary
14:09:51 <pchampin> scribe+
14:10:05 <pchampin> zakim, open item 1
14:10:05 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
14:10:23 <Monsecom> Monsecom has joined #lws
14:10:35 <pchampin> chair: ericP
14:10:43 <uvdsl9> uvdsl9 has joined #lws
14:10:51 <pchampin> ericP: no newcomer, no announcement
14:10:54 <pchampin> zakim, open next item
14:10:54 <Zakim> agendum 1 was just opened, pchampin
14:11:22 <Monsecom> present+
14:11:27 <ericP> Zakim, take up agendum 2
14:11:27 <Zakim> agendum 2 -- Action Items -- taken up [from agendabot]
14:11:32 <uvdsl> uvdsl has joined #lws
14:11:32 <pchampin> https://github.com/w3c/lws-protocol/issues/?q=is%3Aissue%20state%3Aopen%20label%3Aaction
14:11:59 <pchampin> ericP: Hadrian is not here, so let's move on
14:12:26 <pchampin> ... let's also cancel the use-case status as well
14:12:43 <pchampin> zakim, take up agendum 3
14:12:43 <Zakim> agendum 3 -- Discussion: Authorization -- taken up [from agendabot]
14:13:58 <pchampin> ericP: the plan was to give people a sense of how authorization differs from authentication
14:14:25 <pchampin> ... we prepared some slides.
14:15:05 <pchampin> https://hackmd.io/@ericP/Hk1NDnic1g#/1
14:18:30 <pchampin> ... authentication is proving your identity
14:18:45 <pchampin> ... authorization is when you get particular access to a particular resource
14:19:09 <pchampin> ... could be "this person can access this resource", or "any doctor can access any of my health record"
14:19:39 <pchampin> ... WAC is good for the former, it is simple and RDF-native
14:20:05 <pchampin> ... ACP is a little more flexible, but still can't grant access to "health record" (only to a given resource or container)
14:21:28 <pchampin> ... slide 3: important distinction between authorization by identity vs. by capability
14:22:04 <pchampin> ... WAC and ACP do the first
14:22:11 <gibsonf1> q+ to ask about delegation
14:22:36 <pchampin> ... in the example above, I don't know who all the doctors are, I want to delegate that to another server
14:22:47 <ryey> ryey has joined #lws
14:22:50 <pchampin> ... that's authorization by capability
14:22:50 <ryey> present+
14:23:42 <pchampin> ... ACP and WAC could do in principle do that (if I give the IRI of a group rather than a principal), but I don't know if that's implemented
14:24:09 <pchampin> jesse: in ACP, you can express a match based on claims in a verifiable credential
14:24:30 <pchampin> ... but I'm not sure how widely it is implemented (ESS for sure, CSS apparently not)
14:25:06 <uvdsl> It is not part of the ACP spec :) there is just the acp:vc property, nothing more in the spec about that...
14:25:07 <pchampin> ericP: we need to understand what is currently possible, and what can someone expect from every implementation
14:25:36 <pchampin> ... the more we require from every implementation, we higher the bar for implementers
14:25:54 <pchampin> ... the less we require, the more burden on users and applications
14:26:59 <pchampin> ... I'm not sure what Aaron wanted to get through with the "API Scope" item.
14:27:16 <pchampin> gibsonf1: we discussed this last week.
14:27:42 <pchampin> ... An example of delegation was given: you see a doctor, and sign a for allowing anyone from the office to access your data.
14:27:57 <pchampin> ... What prevents us from doing that with WAC, using the WebID of the *office*?
14:28:53 <pchampin> ... What is odd to me is the idea that delegations can be further delegated, so that the initial user has no idea who has access.
14:29:12 <pchampin> ... I'm not sure how capability are used in this context.
14:29:55 <ericP2> ericP2 has joined #lws
14:30:01 <ericP2> q?
14:30:04 <pchampin> ericP: the idea of "by capability" is that the authorization server issues a claim that this person is indeed a member of this group.
14:30:20 <pchampin> ... you suggest to use the WebID of the group instead right?
14:30:41 <pchampin> gibsonf1: that's what we do: we have a hierarchy of groups, and we can use any node of the hierarchy in WAC.
14:31:07 <pchampin> jesse: so gibsonf1, on your server you have a declaration of this hierarchy?
14:31:20 <pchampin> gibsonf1: no, we are simply using standard WebID lookup
14:31:24 <ericP2> q?
14:32:16 <pchampin> dmitri: making a parallel with Google Docs: you can share with specific individuels (by identity) or set up that anybody with the link can view (by capability).
14:32:33 <pchampin> ... and both are possible.
14:33:13 <pchampin> ... Another aspect is being able to identify clients, not just principles.
14:33:50 <pchampin> ... One common critique of identity-based authorization is that your app runs as your user.
14:34:15 <pchampin> ... This is not new to solid, it was a challenge of the 70's mainframes, where any application had access to all the files of the user.
14:34:51 <uvdsl> q+ to ask about "API scope"
14:35:17 <pchampin> ... Capabilities provide guardrails in a world of standalone services that the use delegates to.
14:35:29 <pchampin> q?
14:35:50 <pchampin> gibsonf1: capability effectiveky is public access with a restricted context of action, right?
14:35:57 <ericP2> ack next
14:35:58 <Zakim> gibsonf, you wanted to ask about delegation
14:36:02 <pchampin> dmitri: no, it can do that, but that's not the essential part.
14:36:23 <pchampin> ... capabilities allow you to have flexible social access control, e.g. "anyone with the link can edit this doc"
14:36:40 <pchampin> ... with the social contract that if you have the link, you should not share it with other people
14:36:41 <ryey> q+ on the word "capability": intuitively to me, "things are possible / promised to the data consumer" (i.e. "capable") are "capability"; so what alternative terms should be used for that
14:37:01 <pchampin> q++
14:37:12 <pchampin> q-+
14:37:41 <pchampin> ... but the capabilities do not have to be public access
14:38:14 <ericP2> ack next
14:38:15 <Zakim> uvdsl, you wanted to ask about "API scope"
14:38:40 <pchampin> uvdsl: I wanted to ask about "API Scope", did we reach that?
14:38:56 <pchampin> ericP: we did, but I'm not sure what Aaron meant by that...
14:40:13 <pchampin> jesse: from the discussions I had with Aaron, I think he thinks of @@
14:40:36 <pchampin> uvdsl: I'm still confuse about the values in this row
14:41:13 <pchampin> jesse: my guess is that in "by identity", you need to describe what kind of authentication protocol you use
14:41:52 <pchampin> ... while in "by capability", you need to describe the format of the token you present to the authorization server
14:42:14 <pchampin> ... In theory, the server that issues the access grant can be distinct from your authorization server and your resource server.
14:43:17 <pchampin> ... you only need to prove that you have the capability, not a specific authorization
14:45:03 <pchampin> uvdsl: but the resource server needs to be able to check the token, and becomes an authorization server
14:45:19 <pchampin> ... I thought that the point of an authorization server was to decouple the two
14:45:39 <pchampin> s/to check/to understand the structure of
14:45:54 <Beau> q+ with regards to access grants and ESS services
14:46:13 <Beau> q+ access grants and ess
14:46:16 <pchampin> q+ Beau to ask about access grants and ESS services
14:46:36 <pchampin> "to ask about", "to note that"....
14:46:46 <pchampin> s/"to ask about", "to note that"..../
14:47:22 <pchampin> q?
14:47:24 <pchampin> q+
14:47:51 <pchampin> ... not arguing against the whole idea of capability
14:48:25 <pchampin> dmitri: access token and authorization mechanism vary for may implementation details
14:48:28 <Beau> q-
14:48:34 <pchampin> ... I claim that we need both
14:49:09 <ericP2> ack next
14:49:10 <Zakim> ryey, you wanted to comment on the word "capability": intuitively to me, "things are possible / promised to the data consumer" (i.e. "capable") are "capability"; so what
14:49:10 <Zakim> ... alternative terms should be used for that
14:49:27 <pchampin> ryey: intuitively, "capability" means "being able to do something", so related to functionality
14:49:43 <pchampin> ... but in the examples provided, "capability" seems to be a verifiable token
14:49:49 <gibsonf1> q+ to ask about "simple" capability at Authorization vs resource server
14:50:18 <pchampin> ... I see value in being able to describe a client's "ability".
14:50:48 <pchampin> dmitri: the term "by capability" has been used for a long time, by you are right, it means more in English than in this particular case
14:51:03 <ericP2> scribe+
14:51:57 <ericP2> pchampin: is it true that auth by ID could be modeled as a subset of auth by capability (taking into account that "capability" is scoped)?
14:52:03 <ericP2> scribe-
14:52:15 <uvdsl> q+
14:52:18 <pchampin> pchampin: I assume that "by identity" could be thought as a subset of "by capability"?
14:52:31 <ericP2> ack next
14:52:35 <pchampin> dmitri: its tempting to see it that way, but that's not the case
14:52:51 <pchampin> ... the important difference is who controls the information
14:53:40 <pchampin> s/controls the information/holds the authorization knowledge
14:53:42 <ericP2> ack next
14:53:43 <Zakim> gibsonf, you wanted to ask about "simple" capability at Authorization vs resource server
14:54:03 <pchampin> gibsonf1: on uvdsl's point about the resource server needing to think harder
14:54:51 <pchampin> ... ultimately the resource needs to know what it can deliver; assuming that it can trust the authorization server, a simple message from the authorization server to the resource server telling it "this is what you should deliver" should do the trick, right?
14:55:06 <jeswr> jeswr has joined #lws
14:55:30 <pchampin> ericP: the resource server still needs to understand the token it gets
14:55:49 <pchampin> gibsonf1: what would happen if the ACL were on the authorization server side?
14:56:26 <pchampin> uvdsl: on that topic I hard dmitri say that there is not always an authorization server, but only a server delivering a token
14:56:35 <pchampin> ... for a future discussion, probably
14:56:57 <pchampin> dmitri: the resource server and authorization server blend at some point, this is mostly an implementation detail
14:57:24 <pchampin> uvdsl: we should define what we expect from such each conceptual role
14:57:30 <ericP2> q?
14:57:34 <ericP2> ack next
14:57:57 <pchampin> ... re. pchampin's question, about capability being a superset of identity
14:58:12 <pchampin> ... could I just not write myself a ticket
14:58:38 <pchampin> Dmitri: in low risk situation (e.g. movie ticket) we use capability alone
14:58:59 <pchampin> ... in high risk situation (e.g. plane ticket) we use both (you need the ticket, and *also* to prove your identity)
14:59:53 <pchampin> uvdsl: so capability is not about proving identity, but also proving other things
14:59:56 <pchampin> dmitri: yes
15:00:14 <pchampin> q+
15:00:28 <uvdsl> in particular, it is not tied to defining the structure of a access token
15:00:31 <pchampin> ericP: this is a complicated topic with a lot of terminology
15:00:42 <pchampin> ... Dmitri, any idea of homework for us?
15:00:48 <uvdsl> we could define a structure of an access token for identity-based authorization
15:01:14 <uvdsl> and for capability-based authorization that is required
15:01:38 <pchampin> Dmitri: can't think of any off the top of my head, but my advice would be to read through the OAuth2 specification
15:01:50 <pchampin> ... that helps set a baseline
15:02:07 <ericP2> homework: read OAuth2 spec
15:02:13 <pchampin> https://w3c.github.io/lws-ucs/spec/#glossary
15:02:13 <ericP2> ack next
15:02:28 <ericP2> pchampin: UC&R doc has a glossary
15:02:45 <pchampin> https://w3c.github.io/lws-ucs/spec/#glossary
15:02:48 <ericP2> ... we should make sure it meets our conversation needs here
15:03:14 <jeswr> jeswr has joined #lws
15:05:04 <pchampin> pchampin: next week is ESWC, probably several people from this group will be there
15:05:23 <pchampin> RRSAgent, make minutes
15:05:24 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/26-lws-minutes.html pchampin
15:05:34 <ericP2> uvdsl: requrest no important decisions be resolved while folks are at ESWC next week
15:05:46 <ericP2> RRSAgent, make minues
15:05:46 <RRSAgent> I'm logging. I don't understand 'make minues', ericP2.  Try /msg RRSAgent help
15:05:57 <ericP2> RRSAgent, make minutes
15:05:58 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/26-lws-minutes.html ericP2