Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 20 17:47
    kjetilk commented #136
  • Jan 20 14:10
    sjoerdvangroning commented #61
  • Jan 20 12:28
    kjetilk commented #310
  • Jan 20 10:34
    sjoerdvangroning commented #136
  • Jan 19 12:23
    kjetilk commented #373
  • Jan 19 12:04
    csarven milestoned #373
  • Jan 19 12:04
    csarven labeled #373
  • Jan 19 12:04
    csarven assigned #373
  • Jan 19 12:04
    csarven opened #373
  • Jan 18 16:21
    kjetilk commented #372
  • Jan 18 15:37
    csarven commented #372
  • Jan 18 15:23
    kjetilk commented #372
  • Jan 18 11:08
    RubenVerborgh commented #372
  • Jan 18 10:26
    csarven synchronize #372
  • Jan 18 10:26

    csarven on server-link-auxiliary-type

    Apply suggestions from code rev… (compare)

  • Jan 17 18:03

    csarven on main

    Add missing subsections (compare)

  • Jan 17 17:58

    csarven on main

    Minor (compare)

  • Jan 17 14:45
    bblfish commented #255
  • Jan 17 14:44
    bblfish commented #255
  • Jan 17 08:50
    csarven edited #332
Jordan Shurmer
@JordanShurmer
Sarven Capadisli
@csarven
"meta"? I meant to reconsider renaming the subsection names.. that's why I didn't bother because didn't commit to it yet. There is another subsection eg "Required Server-Side Implementation" --- and prefer to have all headings unique. Will revisit.
and trying to keep the headings and their ids close as possible.
Jordan Shurmer
@JordanShurmer
ok. makes sense. thanks for the context
I used "meta" informally :) as in "info describing the thing, not the thing per se"
Jordan Shurmer
@JordanShurmer

what exactly does this mean?

The root container (pim:Storage) MUST have an ACL auxiliary resource directly associated to it. The associated ACL document MUST include an authorization policy with acl:Control access privilege.

the storage root's ACL has to have at least one person with acl:Control privelege?
("person" being used loosely there)
Jordan Shurmer
@JordanShurmer
I guess 'agent' would have been the right term to use rather than 'person'
Sarven Capadisli
@csarven
It just means that there is an identity associated to a policy that's controlling the target resource (root container).
Sarven Capadisli
@csarven

@/all Meeting with the CredentialsCG is fixed to March 10 at 15:00 UTC and 18:00 UTC (two ~1h sessions) - seems to work for most. CCG presents to SocialCG in the first session, and the other way around in the second session.

They've suggested that an intro to their following work items would be of interest to us: Universal Wallet, DID-Core, Secure Data Storage + others. Also asking any specific work items or areas they should cover.

Please share (here) what you'd like to learn more about.. I'll collect the responses here and send. In https://gitter.im/solid/specification?at=6001ada781c55b09c70d2da8 I suggested some areas:

Identity/Identifiers: WebID, DID
Access control / Capability-based security models: ACL, OCAP
VC data model
Signatures/Encryption
All sorts of Security and Privacy Considerations

I think we should definitely hear more about the security models they're working on. I'm not sure about "Universal Wallet" (as per their suggestion) at this time - not sure if that's high priority.. but I have no strong opinion otherwise.

Henry Story
@bblfish
I am fine with that date. I am just reading up on that and will post questions I have in the Solid Authentication channel. (could do here to).
Sarven Capadisli
@csarven
Re specific questions, let's track them and bring that up in the meeting. For now, let's just agree on a few specs/topics of interest that we'd like from them.
CCG didn't indicate any specific topic from us, so I'll just say we'll do an overview of our key work items (as mentioned awhile back).
Henry Story
@bblfish
I put some initial questions I have over here: solid/authentication-panel#126
Sarven Capadisli
@csarven
Great, thanks!
Fred Gibson
@gibsonf1
A quick question on the persistence of reference URIs in the specs. For example: https://solidproject.org/TR/protocol#resource-type-heuristics With TrinPod we support a full causal systems digital twin, including requirements against systems. We would like to link to the requirements in all the different specs and associate them with our systems so we can automate compliance control. Are the bookmarks etc in the Specs going to persist - or are they not reliable as URI references to mission critical system specs?
My thought is that we duplicate the spec text in the twin such that when it's revisited, we can compare what we have with current published spec and flag if any changes have happened
Also great would be a way to retrieve the master index of spec sections to confirm we have them all or if something has been deleted etc
Martynas Jusevicius
@namedgraph_twitter
the heuristics looks like it's going against URI opaqueness...
Fred Gibson
@gibsonf1
We would also be happy to host a pod that presents a systems model linked to Solid specs for the protocol
Martynas Jusevicius
@namedgraph_twitter
Fred Gibson
@gibsonf1
Maybe I'm asking for something different - a reliable master index of URI's for all the solid specs and their sections
We will be needing that and will have a separate uri (as well as full solid representation as a resource) for each section of the spec ideally set up to pull the latest version as well as provide diffs to previous versions of those specs
Aaron Coburn
@acoburn
I’m not sure how reliable those URLs will be until there is a TR version of the document. Until then, the text and identifiers can all change
Fred Gibson
@gibsonf1
Thanks @acoburn Once the TR version is done, those then can be relied on?
Aaron Coburn
@acoburn
Presumably, yes
Fred Gibson
@gibsonf1
Sounds good. So in the mean time, we can just use current non-stable uris and then map to the final ones when they hit the TR, so that seems workable
Sarven Capadisli
@csarven

@gibsonf1

Are the bookmarks etc in the Specs going to persist - or are they not reliable as URI references to mission critical system specs?

Yes, intended to "persist". In a long enough time, probably not. I've created/proposed a pledge for URI persistence from for the technical reports under solidproject.org: solid/solidproject.org#489 -- you'll have to follow-up on the linked issues.. Can discuss finer details.

I would however take the current state as draft - re "Editor's Draft" as far as the Status of the Document goes. So, expect changes.. there are some units of information that I didn't get to which will probably get renamed.

Regarding your intentions/needs, I have my full support. This is also something that CSS is doing/will do eg. referencing distinct requirements in context of the code that's implementing it.

@namedgraph_twitter

the heuristics looks like it's going against URI opaqueness...
https://www.w3.org/TR/webarch/#uri-opacity

Explain.

@gibsonf1

Maybe I'm asking for something different - a reliable master index of URI's for all the solid specs and their sections

You'll get that eventually re "reliable". See for example: http://rdf.greggkellogg.net/distiller?command=serialize&url=https:%2F%2Fwww.w3.org%2FTR%2Fldn%2F&format=rdfa&output_format=turtle&raw -- W3C's snapshot is frozen.. That's the URI-R (Original Resource).. URI-M is https://www.w3.org/TR/2017/REC-ldn-20170502/ (the URI that W3C pledges for persistence). See PR 489 above.

Sarven Capadisli
@csarven
This message was deleted
GoodNewsEveryone.jpg

Good news everyone!

We're (again) in contact with the W3C Web Platform Incubator CG and this time we're looking into exchanging our notes/work over a meeting:

WICG/WebID#54

(
I've mentioned WICG's work/initiative around "WebID" in the authentication-panel awhile back:
https://gitter.im/solid/authentication-panel?at=5f96a28d3d172d78b39bf4bd
https://gitter.im/solid/authentication-panel?at=5f9aebabd5a5a635f28b8415
)

Date:
February 22 (Monday) at 17:00 GMT (for a ~2h session, TBD) is the proposed date for the meeting.

Sessions:

  • There is no particular format (yet) other than to get an understanding of each others' work. So, brief presentations with a lot of Q&A is a possibility.
  • Anyone is welcome to attend. Please join at least one of the CG's if not already.
  • Sessions may/will be minuted.

Todos:

Justin Bingham
@justinwb
This is great @csarven - confirmed I can be there :white_check_mark:
Sarven Capadisli
@csarven
:) Exciting, isn't it?
Justin Bingham
@justinwb
it is!
Henry Story
@bblfish
Have added it to my calendar. Will need to catch up on what they are doing too now!
Sarven Capadisli
@csarven

Will need to catch up on what they are doing too now!

Story of my life.

Aaron Coburn
@acoburn
@csarven I can attend.
Emmet
@emmettownsend
@emmettownsend
While moving to the next phase of our development on Solid products we found we needed a flexible, robust test suite so that we can test for conformance against the specificaiton. That led me to write a blog with the help of @edwardsph and @RubenVerborgh . Happy to get feedback if you get a chance to have a read. Thanks.
https://inrupt.com/blog/conformance-test-suite
Jordan Shurmer
@JordanShurmer
yes! This is awesome @emmettownsend
Fred Gibson
@gibsonf1
Nice post @emmettownsend , and I definitely vote RDF wherever possible
Justin Bingham
@justinwb
:clap: :clap:
Jordan Shurmer
@JordanShurmer
I would definitely use such a suite of tests btw.
I have a Rust implementation I'm starting to get back to..
wrote my own tiny tests so far, but something like that would be very useful
Justin Bingham
@justinwb
really like the structure of this framework @emmettownsend - this will also do nicely for the shape tree conformance testing that’s about to get underway
Sarven Capadisli
@csarven

Issue/discussion from 2019-07 on supporting RDFa in specifications (based on prior experience): solid/specification#6

One of the reasons why bikeshed/respec (compiling) pipeline is not used for /TR/ , /TR/ecosystem , /TR/protocol , and soon /TR/web-access-control , (and hopefully other reports will follow along) is that it doesn't fit the Solid pipeline ie. what Solid servers (eg. NSS, CSS, ESS..) and applications can do (eg. dokieli). The template is already in place.. and after some more restructuring, we'll have fine-grained statements (eg. all the bits of a requirement). The LDN spec did it up to a point of identifying and describing the requirements - I ran out of time back then to do more with the test suite. Now we have that possibility.

See also Linked Specifications, Test Suites, and Implementation Reports: https://csarven.ca/linked-specifications-reports (2017) for an overview on existing work and how all major components fit together.

Henry Story
@bblfish
For our march meeting with the Credentials community I think I have found a very nice way for us to interact with them via @dmitrizagidulin's did:web proposal. I wrote up details on https://github.com/solid/specification/issues/217#issuecomment-777375570
Sarven Capadisli
@csarven

OK, so, I didn't hear back from anyone re topics with CCG.. besides @bblfish's solid/authentication-panel#126 ... so going to stick to their suggestions, bblfish's, and mention zcap perhaps.

As for meeting with WICG, I take it that we'll stick to the suggested date (Feb 22) - will keep everyone posted if there is any specific agenda beyond intro to Solid's use of WebID, Solid-OIDC, and WICG's WebID.

Henry Story
@bblfish
I am developing some interesting ideas starting from @dmitrizagidulin ideas on did and solid that he posted here https://github.com/solid/specification/issues/217#issuecomment-777101431 nearly a couple of years ago to talk to the CCG about
Sarven Capadisli
@csarven
Right. I think that'll be covered naturally.. (IMO) but will mention it.