https://meet.jit.si/solid-authorization
- Minutes #227
- WAC Editor's Draft PR - we can do a 5-10m (max) Q&A if of interest - csarven
- Consent workflow use case
- UMA like use-case discussion
- Henry Story
- Matthieu Bosquet
- Justin Bingham
- Aaron Coburn
- Sarven Capadisli
- Elf Pavlik
- Eric Prud'hommeaux
Henry: Are the issues linked there gonna get closed?
Sarven: Some. Everything that makes an authorization effective, for example. Is an ACL mode required... Issues about extensions don't close. Some issues linked need to be addressed, such as Client ID. If spec has an answer for it, we'll close.
Henry: I'm interested in extending WAC in simple ways such as adding imports. How do I go about doing that? Should we just clone and edit/improve on it, or add little specs for little pieces, and add links as extensions? Some extensions might make things easier.
Sarven: It will not be in this editor's draft that we would put, for example, imports. The best would be to create an issue specifying the use case in the WAC spec repo.
Henry; We have an issue and a description of how it improves over ACP and WAC, it is still in progress, but how am I gonna build on the existing work?
Sarven: Following in WAC spec would be the way. We need a follow up spec discussion about imports; client IDs and others. Maybe we'll keep editing the editor's draft and create another working draft later.
Henry: Perhaps opening an issue on the WAC editor draft space is the way?
Justin: To Sarven's point, the aim with the work that Sarven just did is we didn't have a good document on the current state of WAC. So let's get it documented. Once that's done, new extensions would be separate as in a different discussion.
Henry: I agree. We now have documented where things were 5 years ago, it is great that it's nicely specced out. But it's just a beginning. Even when it is done, it is going to take another 3 years to go through W3C.
Sarven: Related to closing issues/questions, we should move them to the WAC repo. Especially with the Solid spec. Any new version of Solid WAC will be put into the Solid specification repo. Everything addressing the ED level stuff can be closed.
Henry: Where do meetings about the WAC spec happen? Here or elsewhere?
Sarven: We can do that here if we have an agenda item in my opinion.
Henry: Why do we have two repos?
Sarven: It's historical not purely logic. It's ok to have different repos for stuff that we track. If Solid OIDC needs to move to its own repo, that would make sense. We can use the panel repos as generic and graduate things that are matured to their own repo. THe panels are a meeting point, not necessarily the long term location for the specs.
Justin: That's the intention. Have proposal where you work together and then when it becomes a work item, have its own repo. We can have a lot of proposals and only few become active work items. The panel repo with a proposal folder where things mature and graduate if it makes sense.
Elf: We can keep UCR as well as evaluation on the panel repo.
Aaron: Panels are a mechanism to incubate these proposals. Once they mature, they can emerge to "top-level" projects.
Henry: This seems like UMA.
Justin: They are but this use case is indifferent to the implementation on purpose, so that we can compare UMA vs VC vs not using either. We did a PoC without UMA or VC at all. Once we have that we can illustrate different proposals. Aaron mentioned GNAP. The first case would be agree on a general Use Case that doesn't go into specific implementations. That was the idea behind that. Can walk through: Essentially the idea is agent grant access to an application accross a selected subset of data accross pods.
Henry: Perhaps we should add it to the use case and requirement documents. It reminds me about the "mes infos" project: http://mesinfos.fing.org/. If you go to your electric account It'd be better to have one pod for Alice and several for others.
Justin: what about changing to general terminology as RS? Do we want to make one main use case or several that are focused on a separate dimension? I would rather tend to the latter as a simpler way to start.
Henry: I agree it should be simple. Where does it find that information. But if all Pods are controlled by Alice, then the important point of having several entities controlling is missed. We might need different players otherwise we're not pushing our thinking to the question of how articulating the different players working together?
Elf: What's different with the use case I made about performchart?
Justin: There is overlap, but this use case doesn't cover the pattern of having a trusted party assisting and it's giving performchart access to resources she can manipulate access for.
Elf: Let's clarify requirements in a follow up pull request.
Justin: The reason why I didn't submit this as a PR in the current UCR document, is because it's a layer above WAC and ACP. We might wanna move it to a separate document.
Henry: What is Aaron's use case? Is the important thing that the app should be restricted? Is this really related to Justin's use case?
Aaron: I wanted to express in that use case the distinction between the data model and the protocol. Whether it's ACP or WAC, we need to identify who has access to what. But a protocol that says how to convey to someone in a protocol who I say I am. Not as an individual but as a category of something (citizenship, institution membership...) and the various entities have authority about this. What UMA gives us (it's doable with OAuth and GNAP too), is specific info in the claims gathering stage (VCs...).
Elf: Many use cases we've been focusing on the identity of the requester and here it's some attribute of the requesting party. In the end it doesn't matter who. So it's an interesting distinction. I will try to sketch something which follows UMA's claim pushing using Token Exchange https://datatracker.ietf.org/doc/html/rfc8693 I see it related to what Henry said about the client's need to know what credential to present. The access might not be based on my identity. So we have a way to communicate what needs to be presented. We'll get to the point to how does the UMA server communicates requirements.
Eric: I think this is reminiscent of proof-carrying authentication.
Henry: How to get the attributes is one thing. About Justin's case, it doesn't seem very much related to the one Aaron put forward.
Justin: I purposefully didn't go straight to the VC scenario to show the trusted party usefulness even when you're dealing with identity base. But also this pattern is essential when you do credential based. It's to build on layers. We should have another use case rather than jam it all into one. Both are important.
Aaron: +1 to @justinwb's comment about not wanting to go directly to VC --- the use cases need to be grounded in both general cases (e.g., not with VCs) and specific cases (e.g., with VCs). But packing everything into a single use case complicates things.
Eric: is there a way to tease this apart more by coming up with a variant where VCs would not apply?
Henry: Oh the web site is also translated into English too, and they continued working on the project http://mesinfos.fing.org/english/
- Aaron to amend the minutes and Matthieu to merge once done (DONE)