Scope needs to be tightly defined with narrow focus

[csarven]

Recommend a set of practices needed for data security for Solid Pods, and for both server and client software, including use of appropriate authentication, authorization, verification, identity, and other standards, integrating existing outside efforts.

This is too broad. It is also suggesting best practises and/or guidelines on works that are still under development or have not even been incubated in the CG. Moreover, recommending BPs on components that are at the same time deemed to be out of scope for the WG.

Recommend a set of protocol behaviors and best practices to request and grant access to data stored in Solid Pods.

Define a protocol for state synchronization regarding changes to resources in Solid pods.

Noting again that most of this is not incubated or has sufficient implementation feedback.

[melvincarvalho]

Define a protocol for state synchronization regarding changes to resources in Solid pods.

Agree with @csarven re: this item, which may significantly increase the workload for the WG.

[elf-pavlik]

I think those might be good examples of what this bullet point might aim to cover.

• Security considerations for integrity of solid:oidcIssuer triples solid-oidc#219
• UMA Claims Pushing with DPoP-bound Solid OIDC tokens solid-oidc#159

I don't think we still have crystal clear the dependency structure between all the specs and where each requirement and security consideration belongs. Possibly some details might need to be captured as WG Note until a proper specification can be worked on.

[kaefer3000]

Section 2 "Scope" rightly talks about many different ends (authentication, security, state synchronisation, ...) that the Solid Protocol should achieve. Section 2 mentions one specific means to achieve an end (authentication), the technology OpenID Connect. OIDC may be a good choice to achieve authentication, but this looks imbalanced.

Therefore, I propose to remove the mention of OIDC from 2. Scope.

(copied from #29 as per request of @csarven such that #29 can be closed.)

[pchampin]

I believe that #34 mostly addressed the concerned raised in this issue. @csarven ?