Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:07
    csarven synchronize #346
  • 00:07

    csarven on n3-patch

    Stabilise n3-patch spec:require… (compare)

  • Dec 05 23:02
    csarven synchronize #346
  • Dec 05 23:02

    csarven on n3-patch

    Minor (compare)

  • Dec 05 22:47
    csarven synchronize #346
  • Dec 05 22:47

    csarven on n3-patch

    Minor (compare)

  • Dec 05 20:52
    csarven synchronize #352
  • Dec 05 20:52

    csarven on authoritative-contained-resource-data

    Update protocol.html Co-author… (compare)

  • Dec 05 20:48
    csarven synchronize #352
  • Dec 05 20:48

    csarven on authoritative-contained-resource-data

    Update protocol.html Co-author… (compare)

  • Dec 05 20:01
    RubenVerborgh commented #352
  • Dec 05 16:50
    csarven commented #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven review_requested #352
  • Dec 05 16:48
    csarven commented #352
  • Dec 05 16:39
    csarven synchronize #352
  • Dec 05 16:39

    csarven on authoritative-contained-resource-data

    Minor Add contained-resource-metadata… (compare)

Tim Berners-Lee
@timbl
There was a thing called ‘webizen’ which allowde you to search by name. It did not scarape pods, you ha to add a webid by hand. Or mayeb using an API from an AP. Ithink alas the domain name has lapsed
Tim Berners-Lee
@timbl
Well found!
Aaron Coburn
@acoburn

As mentioned in today's authentication panel meeting, there is now a browser-based test suite for Solid-OIDC available at https://solid.github.io/solid-oidc-tests/

The code tests authorization_code flow with client identifiers, using PKCE and DPoP. There are more tests to add, and contributions are welcome at https://github.com/solid/solid-oidc-tests

Fred Gibson
@gibsonf1
@csarven & @timbl That would be pretty nice to have a search engine that would hit the various IDP's with a common search api to find people - that is, having a common search api for the server to locate webids would be very good
Fred Gibson
@gibsonf1
@acoburn That is extremely cool. I ran https://github.com/solid/solid-oidc-tests on https://stage.graphmetrix.net and 2 issues were found (listings in the config). I just did a new build fixing both, so now all tests pass
Great work, and great approach to making it extremely easy to test and to see which spec is involved with the test
image.png
Tim Berners-Lee
@timbl
Yes. Veey nice
Fred Gibson
@gibsonf1
@acoburn One note on the test, it only worked with an existing user - trying to register a new user with the test didn't work as at least in the case of TrinPod the server received some unexpected data duing the registration
Matthias Evering
@ewingson
@gibsonf1 what do you mean exactly with "worked with an existing user..." ? which "issuer URL did you use ? see https://gitter.im/solid/test-suite
Aaron Coburn
@acoburn
@gibsonf1 that is by design. Solid-OIDC does not define user registration flows. The tests only verify those things that are in scope of the Solid-OIDC specification.
Matthias Evering
@ewingson
I guess running the test kindof "with an existing user" (i.e. logged-in) these messages https://solid.github.io/solid-oidc/#discovery would disappear
Alain Bourgeois
@bourgeoa
image.png
@acoburn the tests fail on solidcommunity.net on webId scope. There is a unauthorized in popup window ?
Aaron Coburn
@acoburn
Does NSS support Solid-OIDC client identifiers?
Sarven Capadisli
@csarven

@gibsonf1

@csarven & @timbl That would be pretty nice to have a search engine that would hit the various IDP's with a common search api to find people - that is, having a common search api for the server to locate webids would be very good

Yikes. Maybe? That needs a major Privacy Consideration. If people want to opt-in (give consent to be discovered and also conditions for resuse from an index/database), okay.

Tim Berners-Lee
@timbl
Do you not think someone putting their name in theor public profile if already demonstrably making it public?
Fred Gibson
@gibsonf1
@csarven For sure, it would only be the information people allow to be public (agreed @timbl )
elf Pavlik
@elf-pavlik
@csarven what do you think about setting up something like https://github.com/marketplace/actions/prettier-action for the spec document?
you can preview how it would look formatted on https://prettier.io/playground/ by setting parser to HTML, I suggest --print-width up to 120 characters /cc @justinwb
I don't know how people are currently reviewing long lines like in https://github.com/solid/specification/pull/352/files
Sarven Capadisli
@csarven

@timbl Public, readable, sure. Aren't data protection acts/regulations specific about the use ? Indexability, archivability,...

Stuff like ODRL / DPV sets specific constraints and conditions.

Gets interesting considering identifiers and descriptions..

The WAC spec for example has a policy with specific ODRL permissions assigned by the Solid CG https://solid.github.io/web-access-control-spec/#document-permission

Aggregate Archive Concurrent Use Derivative Works Derive Digitize Display Distribution Index Inform Install Notice Present Print Read Reproduce Reproduction Stream Synchronize Text-to-speech Transform Translate

DPV includes processing categories: https://dpvcg.github.io/dpv/#vocab-processing-categories

I didn't get around to updating my WebID profile with this..

Sarven Capadisli
@csarven
@elf-pavlik I'll look into it, thanks. The line length is not relevant in how I review PRs. I don't apply a single approach for all kinds of PRs either. For a PR like the one you pointed out, I'd see what's actually communicated in the Web browser. That's the intended / target reading. I'm not married to GitHub's UI. (You know.. kind of like how we in Solid preach about not forcing people to use a single app's UI for particular data...)
Sarven Capadisli
@csarven
I took the bait and looked into prettier. It doesn't appear to have semantic understanding of HTML or RDFa. Number of characters per line is not the issue here. In case you haven't seen, check out solid/specification#261 -- It'd be great if we didn't continue to debate on that? The specs will be soon enough served off a Solid server, and there is no particular reason why can't read-write against the resource. "Eating our own cooking." Whereas prettier goes under the same category of approaches that require compiling. The opposite direction... with more third-party tooling and complicated pipeline.
elf Pavlik
@elf-pavlik
Adding new sections can be easily reviewed by looking at rendered HTML. For changed text seeing clear diff can come helpful. If others find diffs with long lines easy to review I think there is no real issue to solve.
Fred Gibson
@gibsonf1
I attended the authentication-panel meeting this week https://github.com/solid/authorization-panel/blob/draft-minutes/meetings/2021-11-17.md and in part presented the TrinPod approach to supporting path uris per Solid Spec (dynamically generated from tags and ldp:contains through the public facing turtle interface) with permanent uris for all resources such that a resource can be in more than one container. It was recommended that we explain the approach here for how we are doing things, I guess for the benefit of other potential implementers. Just wondering if there is interest here, and if so, what the next steps would be?
Fred Gibson
@gibsonf1
I just noticed this warning on Inrupt's developer tools area:
image.png
Where it states: "due to known security issues with WAC, WAC is not recommended for Production environments." What are those known security issues?
Martynas Jusevicius
@namedgraph_twitter
I'm curious too
More likely issues with their implementation of WAC
Fred Gibson
@gibsonf1
Yes, thats what I think too - and I think making that claim is not a great idea unless it is fully true
Martynas Jusevicius
@namedgraph_twitter
also Inrupt being behind Solid and its spec and then not implementing the spec looks kinda weird to me
elf Pavlik
@elf-pavlik
It might be related to limitations removed for authz-ucr in this commit https://github.com/solid/authorization-panel/commit/740ecca4aec8e426691d921efa03a614242a850d#diff-970cc50352376ec44b2aefe7e5808328ae8d203737ca4fd966d2513705cc640b
They were removed from the document because we generalized wac-ucr into athz-ucr and we were expecting that those limitations will come up again while evaluating WAC against requirements from authz-ucr
Fred Gibson
@gibsonf1
So that list of use cases is not related to security, but added functionality (for example, we will do things like conditionals for time etc by deploying acls in a process)
So is there a "known list of security issues with WAC" ?
I would say the major issue here is that if WAC does not have any known security issues, and Inrupt claims that it does, then by inference any Implementation (like ours) that uses WAC in production is insecure and should not be used
So its a very big deal to publicly make that claim with respect to other systems, unless its true and there is an exact known reason why
Sarven Capadisli
@csarven

Pavlik is utterly wrong about the removal reason:

They were removed from the document because

They were removed because I asked them to be removed : solid/authorization-panel#173 . Literally:

Solution-centric references have no place in a UCR document.

Period.

elf Pavlik
@elf-pavlik

@csarven didn't participate in the early work of the panel so he might be unaware of earlier work. Anyhow, the reason that section was removed from that document doesn't really matter, but limitations of WAC were documented there. Those limitations can lead to over-permissioning which can cause security issues.

we were expecting that those limitations will come up again while evaluating WAC against requirements from authz-ucr

Listed WAC limitations were supposed to come up again in https://github.com/solid/authorization-panel/blob/main/proposals/evaluation/index.md unfortunately, we didn't follow through with properly evaluating existing proposals.

Sarven Capadisli
@csarven
So claims are made without an evaluation and thrown into a UCR document. Then you didn't finish the evaluation or understanding WAC or extensions where necessary. Got it.
@bblfish:matrix.org has been doing quite significant work there helping the panel understand the mechanisms - most are on record.. in issues and so on. AFAICT.
bblfish
@bblfish:matrix.org
[m]
Hi! 👋 Thanks for helping me stop thinking about Covid. That's a mind killer.
Sarven Capadisli
@csarven
authorization-panel first tried to pass a UCR document without the "R" in place :joy: ... which I also raised a flag about. And prior version of that document was solutions-engineering.. with more flags being raised. But yea, tell me more about limitations.
bblfish
@bblfish:matrix.org
[m]
I don't see a reason why WAC should have security limitations. If there are secruity problems they should be brought up and fixed.
Fred Gibson
@gibsonf1
:thumbsup:
bblfish
@bblfish:matrix.org
[m]
I think there is good reason to believe that WAC is closely inspired from RelBAC, so it should not be difficult to give it formal foundations.
solid/authorization-panel#150
Fred Gibson
@gibsonf1
I would like to know what (those well known problems claimed publicly by Inrupt), if anything, is not secure about the WAC protocol (and this does not include how implementers do it, whether file based, OWL, or otherwise)
Fred Gibson
@gibsonf1
@timbl Could you possibly find out why Inrupt says WAC is not for production use because of "known security issues" here: https://docs.inrupt.com/developer-tools/javascript/client-libraries/tutorial/manage-access-control-list/ ?
6 replies