Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 03 16:06

    csarven on main

    Update work-item-technical-repo… (compare)

  • Feb 03 15:21

    csarven on main

    Add view potentialAction for un… (compare)

  • Feb 03 13:35

    csarven on main

    Add Solid QA work item (compare)

  • Feb 03 11:48
    csarven commented #495
  • Feb 03 11:18

    csarven on main

    Update CG URLs Update introduction Update technical-report-descrip… and 1 more (compare)

  • Feb 03 11:13

    csarven on main

    Add Solid QA (#495) * Add Soli… (compare)

  • Feb 03 11:13

    csarven on qa

    (compare)

  • Feb 03 11:13
    csarven closed #495
  • Feb 03 11:13
    csarven commented #495
  • Feb 03 11:00
    csarven synchronize #495
  • Feb 03 11:00

    csarven on qa

    Update abstract in response to … (compare)

  • Feb 02 16:14
    csarven commented #498
  • Feb 02 16:14

    csarven on main

    Add 2023-02-01 agenda and minut… (compare)

  • Feb 02 16:14

    csarven on 2023-02-01

    (compare)

  • Feb 02 16:14
    csarven closed #498
  • Feb 02 11:42

    csarven on main

    Update some links to the redire… (compare)

  • Feb 02 11:22

    csarven on main

    Update societal-impact-review s… (compare)

  • Feb 02 10:41
    csarven synchronize #498
  • Feb 02 10:41

    csarven on 2023-02-01

    Add clarifications to 2023-02-0… (compare)

  • Feb 02 10:12

    csarven on 2023-02-01

    Apply suggestions from code rev… (compare)

Sarven Capadisli
@csarven
I don't know about every.. but WAC doesn't require it at the moment, as you know. There are some things that's hinting at using acl:owner (or something similar from what I've gathered) but that's not specified. I do think it is reasonable to put it under solid/terms.
Aside: This conversation makes me think of WAC-Allow's parameters and access modes.
Aaron Coburn
@acoburn

Aside: This conversation makes me think of WAC-Allow's parameters and access modes.

completely agree

Sarven Capadisli
@csarven
So, if solid:owner is equivalentProperty acl:owner that'd be okay? :) IMO, for "podOwner" to be sensible, domain probably needs to be a "Pod". This is where I was going with using acl:owner on pim:Storage.
Justin Bingham
@justinwb

The question is: does every authZ mechanism define their own owner property, or can one be added to the solid namespace and thereby be more generally applicable?

should be under solid imo

Dmitri Zagidulin
@dmitrizagidulin
any chance i can convince ya’ll to use ‘controller’ instead of ‘owner’?
(so that we can match the w3c community terminology)
Matthieu Bosquet
@matthieubosquet
@dmitrizagidulin could you link to relevant documentatoin on the w3c terminology?
Matthieu Bosquet
@matthieubosquet
+1 for the owner/controller property being under solid with domain solid:Pod
Sorry if the question has already been answered, but is there or should we create a class and predicate for WebIDs?
Something like solid:webId & solid:WebID.
Since really agents in the solid context are identified by a WebID and a WebID really is just a URI identifying an Agent.
I'm wondering if solid:WebID would not be a better fit as range of an owner property or as domain of solid:oidcIssuer instead of a vcard:Agent which might have a solid:webId or not.
Sarven Capadisli
@csarven

@matthieubosquet If of interest: https://github.com/solid/specification/issues/153#issuecomment-616464435 , https://gitter.im/solid/chat?at=59f890fce44c43700a9dc81f or see links in https://github.com/solid/contacts-pane/issues/18#issuecomment-725963009 .

As long as the needs are well documented and specs are referring to them, all fine. Not sure about a webid Class but can probably get more out of a property.

I'm not opposed to "podOwner" property or "Pod" class -- and which namespace is to throw it under is the least of concerns IMO -- but I'd like to hear more from people about what they think/expect with the differences are with root container (pim:Storage) or maybe even server origin or root URI path..

re "controller" or "owner" etc .. see links above. Plenty of existing discussion in chats/issues.. not worth repeating here unless there is some new information. tl;dr: both are fine as synonyms but can obviously differ in their meaning and purpose. Don't forget to throw in "creator" or "admin" or "authority" for fun and profit.

Matthias Evering
@ewingson
Don't forget to throw in "creator" or "admin" or "authority" for fun and profit.
I like this thought. it made me smile...
@csarven do you need confirmation for participation in the w3c meetings ? I won' t make it on feb 22nd but on march 10th I will attend both as fly on the wall.
Sarven Capadisli
@csarven
@ewingson No need now.. just attend as you can/like. Thanks.
Justin Bingham
@justinwb
@csarven is this meeting still happening?
i’m at https://meet.jit.si/solid-wicg-identity-authentication but there’s no one else here
Justin Bingham
@justinwb
ah is it 5 hours from now
Sarven Capadisli
@csarven
:)
Fred Gibson
@gibsonf1
Is there a preferred language predicate to use for setting a user's language?
there is this, but not quite the right thing: https://schema.org/knowsLanguage
Dev380
@Dev380
Hello. I have a few questions about Solid:
1) So, traditionally data is stored by the platform, and you have to trust them with your data and the ability to download your data, etc. But with Solid, you have to trust the pod. Isn't this just moving the problem a level back? 2) Most people are too lazy to make new pods for every app, so then wouldn't a chess website know your name (for example) in Solid but not in the traditional model? 3) What if a Solid app just downloads the data off your pod each time you use it?
Henry Story
@bblfish
Security, like knowledge is not an all or nothing matter. You need many different pieces of the puzzle to fit together.
But you can progress towards better architectures.
Sarven Capadisli
@csarven

@gibsonf1 I think we discussed "preferred language" somewhere but can't find it off hand now - if you come across it, let me know. It is along the lines of "preferred license" that can be used as part of a pim:configurationFile or something else ( solid/vocab#6 ). It can guide the application. I'd suggest to be clear .. is the intent to tell the User Agent (eg Accept-Language) - and whether that should just be controlled by the UA, so not a problem to solve here - or application internationalisation (software to adapt to user's preferred language) eg: https://github.com/linkeddata/dokieli/issues/242#issuecomment-409504926 .

You may also want to note the Cognitive Characteristics Ontology: http://smiy.sourceforge.net/cco/spec/cognitivecharacteristics.html . I use cco:skill here: https://csarven.ca/cv

Sarven Capadisli
@csarven
Made a minor update to use ESCO's language skills ( http://data.europa.eu/esco/skill/L ). Fun.
Fred Gibson
@gibsonf1
@csarven impressive!
Henry Story
@bblfish
Does Solid distinguish between a URL ending with / and the same one minus the /? What is the difference in terms of files on the file system? It looks like it does according to the node-solid resource mapper.
I see that It looks like https://an.example/foo requested with text/html would return resource https://an.example/foo.html whereas https://an.example/foo/ could return foo/index.html if the default for a dir is set to index.html
Henry Story
@bblfish
Is that specified, or is that a node-solid choice? I guess the idea is that foo.html is the external view of the container, and foo/index.html the internal view of the container.
Sarven Capadisli
@csarven
@bblfish Container and contained resources can be distinguished. If /foo exists, /foo/ can't exist, and vice versa. It doesn't say anything the URI (Template) for representation URLs https://solidproject.org/TR/protocol#uri-slash-semantics
so, servers can use Content-Location if they want to.
Henry Story
@bblfish
If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource.
that seems to say the opposite.
Behaviour pertaining to authorization MUST proceed this optional redirect
that is bad english. I am not sure what that means.
Should I open an issue?
Sarven Capadisli
@csarven

If /foo/ exists and server implements redirecting (eg. /foo to /foo/), then when /foo is requested, redirect should only happen if agent is authorized to know about the existence of /foo/. If it doesn't implement redirect, 403 will be returned (or returning 404 if agent can read /)

I think we can rephrase that... I think it should move into security considerations because it is not unique to slash stuff

IIRC, Tim wasn't keen on having a MAY for the redirect. I think I said we can lowercase it
Henry Story
@bblfish
I opened an issue to capture the problem. solid/specification#240
I think you meant must preceed (i.e., come beforehand) not must proceed (must do).
Jordan Shurmer
@JordanShurmer
@bblfish URL ending with a / will be containers. It's defined in the spec somewhere. one sec
Oh.. I see there was already discussion about it :D sorry
@Dev380 Yes what you bring up is still a reality that needs to be dealt with in various ways. I.e. if you, as a user, don't trust an app then you should not give it permission to access your data. Solid has no way of limiting what they do with your data once they access it.
However, IMO Solid gives encourages apps to build trust with their users (e.g. publish their source code so we know what they're doing). Maybe some day there would be various ways to build trust into the system to
Henry Story
@bblfish
It would be quite possible to build a Java App platform that sets the right security limitations on Apps so that they can do the right thing.
Ie. One should not think one is totally limited by the browser. Android has 70% or more market share.
But it would require thinking about how to do security on those platforms too....
Henry Story
@bblfish
I found three use cases for why one should not be as strict as specified for /foo necessarily redirecting to /foo/ solid/specification#242
Henry Story
@bblfish
@mwherman2000 I think it is understood that DIDs and https URIs have the same semantics. The problem in #242 is not about semantics of URIs but as I understand it now, about reasonable default behaviors.
Sarven Capadisli
@csarven
Thanks. Will get to this issue. I'm sort of on the fence on this.. well, maybe a bit leaning on the idea of not allowing /foo and /foo/ to exist at the same time for different resources. There may be a security implication but I can't quite formalise it right now -- kids being loud.. and it is like dinner time etc.