Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 09 01:05
    elf-pavlik commented #447
  • Aug 08 15:22
    TallTed commented #447
  • Aug 07 02:14
    almereyda opened #448
  • Aug 06 09:58
    melvincarvalho commented #447
  • Aug 06 09:55
    melvincarvalho commented #447
  • Aug 06 09:44
    melvincarvalho commented #447
  • Aug 06 09:41
    melvincarvalho commented #447
  • Aug 04 19:09
    barath commented #447
  • Aug 03 22:40
    ThisIsMissEm commented #447
  • Aug 03 17:14
    kjetilk commented #409
  • Aug 03 17:08
    acoburn synchronize #409
  • Aug 02 16:03
    elf-pavlik commented #447
  • Aug 02 15:56
    elf-pavlik commented #447
  • Aug 02 13:38
    scenaristeur commented #447
  • Aug 02 12:34
    timbl commented #447
  • Jul 28 16:33
    csarven reopened #409
  • Jul 25 12:15
    elf-pavlik commented #447
  • Jul 22 15:50
    justinwb assigned #447
  • Jul 22 15:50
    justinwb opened #447
  • Jul 06 14:22
    csarven commented #224
Sarven Capadisli
@csarven

@/all Solid meetings are using different video conferencing tools/services. They are controlled by different parties. No single party needs to control, start/end meetings or require proprietary tooling to be installed on desktop or run in the browser. We can simplify and keep things neutral - as much as we reasonably can - for the W3C Solid Community Group.

Fortunately, there are already have open source tool/platform/service options eg. Jitsi. I suggest for all spec / panel meetings to happen at:

If anyone would like to raise an objection, please share your preferences or expectations.

(Plenty of other Jitsi instances to choose from: https://jitsi.github.io/handbook/docs/community-instances . We could - although this is a lot more work - even host our own at meet.solidcommunity.net or something but that's probably a bit far down the road.)

Yvo Brevoort
@ylebre
@csarven not collaborating with @cniekel yet :) What we are thinking is in the lines of, what if I wanted to move my solid storage pod from a US-based service into a EU-based service. The URIs would need to move from solid.us to solid.eu somehow. The 410 (specifically, a tombstone for a resource that is no longer there) came to mind because it would require the old location to know that a resource used to exist on that location. That same thing could be used to know that a resource has a new location to trigger a redirect.
Sarven Capadisli
@csarven
If you control solid.us and solid.eu, then definitely redirect.
Assuming you want continuous operation. Without the redirect, people obviously can't find the new location.
csarven @csarven pokes @dmitrizagidulin
Henry Story
@bblfish
Is this the right way to write this WAC-Allow: user="read,append,write" ?
If I got it wrong, let me know here. I'll fix it up in this issue solid/authorization-panel#141
Jeff Zucker
@jeff-zucker
AFAIK, yes user="read append write",public="read"
Henry Story
@bblfish
ok cool
Jeff Zucker
@jeff-zucker
This message was deleted
3 replies
Oops one sec
No commas inside the quote, this is correct : user="read write append control",public="read"
1 reply
Emmet
@emmettownsend
just had a read
interesting.....
the Agent is allowed the access modes.
the Policy allows the access modes
the Resource allows the access modes (kind of. as far as the client is concerned)
If we were to translate to triples the way you sugggest then the last one would be correct and the domain would be a resource??
Henry Story
@bblfish
The usage in a Link header seems to suggest that. But if you have a direct link to the mode, then you are missing which agent is allowed.
Jeff Zucker
@jeff-zucker
So there is an implied relationship, something like "Resource regulatedBy Policy"?
2 replies
Emmet
@emmettownsend
So the link header pertains to the agent who made the request
Jeff Zucker
@jeff-zucker
For describedBy and acl relationships, it's the resource that is the subject.
Emmet
@emmettownsend
I think perhaps we need to change the domain for acp:allow to resource rather than policy
Henry Story
@bblfish
@emmettownsend I guess the thing is that you are not just using acp:allows in Link headers. You are also using it in the ACP Document, where it makes sense to have it be related to a acp:AccessPolicy
Emmet
@emmettownsend
mmmmmmmmm yes
in that case perhaps we need another term.
because the domain is definitely Policy when used in the other case.
Jeff Zucker
@jeff-zucker
The pretty picture in the ACP Document shows the relationship acp:accessControl between a Resource and it's AcessControl Resource, but no relationship names for what's between the Resource and its Rules and Policies
Emmet
@emmettownsend
hold on I'll have a look
oh the first diagram.
if you keep reading it builds it up piece by piece until the full diagram is constructed
Jeff Zucker
@jeff-zucker
Very nice, thanks. Exactly what I was looking for.
Michiel de Jong
@michielbdejong
Just read an interesting quote from Oz: "Notes On Compatibility
If you have an existing application that was built against the Node Solid Server it is likely that changes will need to be made to the application in order to work with the Enterprise Solid Server. This is due to the latest changes in the spec not being reflected in the Node Solid Server. " - can you comment on that @csarven?
I mean, see https://github.com/solid/specification for the latest changes in the spec
Henry Story
@bblfish
I opened solid/authorization-panel#139 "List of WAC implementations" to get an overview of the different implementation experiences of WAC. Please if you have an implementation send us your feedback.
Sarven Capadisli
@csarven

Michiel, I think Oz and Emmet can clarify the statements in the blogpost. My interpretation - take this as informal as it can be: the statements in the blogpost alludes to the current activities in the authorization-panel. See the post's link to https://docs.inrupt.com/developer-tools/javascript/client-libraries/tutorial/manage-acp/ for clarification, where it states "ACP is an alternative to Access Control Lists and is being proposed for inclusion in the Solid specifications." That is accurate in that there are a couple of initiatives running in parallel, and this is what I can formally summarise on the current state of the CG's activities:

The authorization-panel is currently/generally transitioning from the Use Cases that was proposed to coming up with (Non-)Functional Requirements. The Requirements will actually be what all proposed solutions need to address as normative spec text. There is also the UC survey to determine which UCs the Community Group is interested in seeing/using/developing for servers/applications so as to help determine and prioritise which UCs the authorization-panel should focus on. At the same time, ACP is a WIP proposal addressing some of the UCs in which are not deemed to be covered by WAC. The details pertaining to delta/overlap between WAC and ACP are also being worked on. To make things even more interesting, there is the possibility of an Authorization Framework for the Solid Ecosystem which might tie up the work, allowing wider coverage of UCs by different (mostly/hopefully orthogonal) authorization systems.

So, it is all moving forward. Things should clear up in the next weeks/month(s?) As for the current Solid Ecosystem, WAC is currently a MUST for Authorization. The output of the authorization-panel will be proposed for the Ecosystem.

Michiel de Jong
@michielbdejong
Thanks, that's what I thought :) So it's ESS that's ahead of us, not NSS that is behind. I'll ask Oz to rectify his statement.
Henry Story
@bblfish
There are some good ideas in ACP, but as we are going through the documentation made available we are finding issues (as the one discussed above for example).
Also I am not yet sure it needs to diverge as dramatically from WAC as it does, there is a lot more in common than appears on first sight.
Ruben Verborgh
@RubenVerborgh
The other difference is authentication, where CSS uses DPoP.
Michiel de Jong
@michielbdejong
I think all servers now support DPop, and NSS is the last server to additionally still support legacy-pop.
PSS and Nextcloud also don't support legacy-pop.
But they do support WAC. :)
Sarven Capadisli
@csarven
@michielbdejong Cool. Ccould you mention the WAC implementations at the issue Henry shared earlier?
Michiel de Jong
@michielbdejong
Has there been a spec change where "Shape Validation with Shex" became required?
Sarven Capadisli
@csarven
No, Shex is one possibility. Justin can fill in on data-interoperability-panel though.
Michiel de Jong
@michielbdejong
OK, thanks!