You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently joined the Solid CG and would like to help with #338 as an individual contributor.
I compared the current SAI Editor's Draft (§8.1.2, §9.4 and §10.3 through §10.5) with LWS 1.0 §11, together with SAI issues #327, #328 and #222.
My current reading is that an LWS Access Grant is an authorization record created by the storage controller, not a bearer credential. It already models the assignee, actions, targets, constraints and a POST/DELETE lifecycle. The open SAI work on Delegated Data Grants additionally raises questions about the source grant, attenuation, issuance and policy propagation on the owner's side, and ancestor revocation.
Would a small compatibility matrix plus protocol neutral negative conformance scenarios be useful as a first deliverable? For example:
a descendant grant must not widen actions or targets, or weaken parent constraints;
a missing, expired or revoked ancestor must invalidate its descendants;
storage, owner and assignee rebinding must fail;
a delegated grant must not become effective before successful issuance and policy propagation by the data owner's Authorization Agent;
replay or duplicate issuance must not create additional authority.
Before drafting a PR, could you confirm whether #338 is intended to cover only the request/grant protocol and lifecycle mapping, or also the delegation validation invariants from #327? Should the first deliverable live in the SAI specification/primer, or be contributed to the LWS migration note in w3c/lws-protocol#66?
One concrete detail I noticed: the current GrantData JSON Schema has additionalProperties: false but does not declare delegationOfGrant, while SAI §10.5 defines that property for DelegatedDataGrant. Should this be handled as a separate small fix, or is it intentionally waiting for the #338 alignment?
I'm currently working on variuos changes in https:/sai.js.org which will inform changes in the spec and primers.
Would you be interested in having a call where I could share with you what I expect to change in specs relativelly soon?
I see that you have joined Solid CG, if you happen to join next CG meeting we can take it from there, otherwise I'll write you an email sometimes after the CG meeting on Wednesday.
No worries, I recommend adding ics feed at the botom of https://www.w3.org/groups/cg/solid/calendar/ to your calendar. That gives you stable reference and handles timezones. I hope you don't mind but I'll starting hiding some of our chatter here as off-topic, this way we can follow up later in this issue about next steps for access requests and grants alignment.
Activity
Math1987 commentedon Aug 17, 2026
Hi,
I recently joined the Solid CG and would like to help with #338 as an individual contributor.
I compared the current SAI Editor's Draft (§8.1.2, §9.4 and §10.3 through §10.5) with LWS 1.0 §11, together with SAI issues #327, #328 and #222.
My current reading is that an LWS Access Grant is an authorization record created by the storage controller, not a bearer credential. It already models the assignee, actions, targets, constraints and a POST/DELETE lifecycle. The open SAI work on Delegated Data Grants additionally raises questions about the source grant, attenuation, issuance and policy propagation on the owner's side, and ancestor revocation.
Would a small compatibility matrix plus protocol neutral negative conformance scenarios be useful as a first deliverable? For example:
a descendant grant must not widen actions or targets, or weaken parent constraints;
a missing, expired or revoked ancestor must invalidate its descendants;
storage, owner and assignee rebinding must fail;
a delegated grant must not become effective before successful issuance and policy propagation by the data owner's Authorization Agent;
replay or duplicate issuance must not create additional authority.
Before drafting a PR, could you confirm whether #338 is intended to cover only the request/grant protocol and lifecycle mapping, or also the delegation validation invariants from #327? Should the first deliverable live in the SAI specification/primer, or be contributed to the LWS migration note in w3c/lws-protocol#66?
One concrete detail I noticed: the current GrantData JSON Schema has additionalProperties: false but does not declare delegationOfGrant, while SAI §10.5 defines that property for DelegatedDataGrant. Should this be handled as a separate small fix, or is it intentionally waiting for the #338 alignment?
elf-pavlik commentedon Aug 17, 2026
Hi @Math1987,
I'm currently working on variuos changes in https:/sai.js.org which will inform changes in the spec and primers.
Would you be interested in having a call where I could share with you what I expect to change in specs relativelly soon?
I see that you have joined Solid CG, if you happen to join next CG meeting we can take it from there, otherwise I'll write you an email sometimes after the CG meeting on Wednesday.
https://www.w3.org/groups/cg/solid/calendar/
Math1987 commentedon Aug 18, 2026
elf-pavlik commentedon Aug 18, 2026
Math1987 commentedon Aug 19, 2026
elf-pavlik commentedon Aug 24, 2026
Math1987 commentedon Aug 25, 2026
Math1987 commentedon Aug 26, 2026
elf-pavlik commentedon Aug 26, 2026
Math1987 commentedon Sep 3, 2026
elf-pavlik commentedon Sep 3, 2026
No worries, I recommend adding ics feed at the botom of https://www.w3.org/groups/cg/solid/calendar/ to your calendar. That gives you stable reference and handles timezones. I hope you don't mind but I'll starting hiding some of our chatter here as off-topic, this way we can follow up later in this issue about next steps for access requests and grants alignment.