Does the value come from the protocol or the applications? #71
Conversation
|
Unsure if this is a discussion or for comment on the PR text. The PR text is truly excellent. It reads very well. Slight nit is that it can be used with server side apps too. In fact in the end server side may be more than client side. However, I dont see that the text needs changing.
Both.
Stage (1) comes first, then stage (2) comes later, if all goes well. |
charter/index.html
Outdated
| @@ -191,7 +191,7 @@ <h2>Motivation and Background</h2> | |||
| <h2>Scope</h2> | |||
|
|
|||
| <p> | |||
| <span class=new>The scope of the Working Group is to define a web protocol for use between client-side applications, on the one hand, and storage and identity servers, on the other, allowing</span> users to keep authority over their data, identity, and privacy. | |||
| <span class=new>The scope of the Working Group is to define a web protocol that client-side applications can use to authenticate users and store their data with user-chosen identity and storage servers. Applications that use this protocol can more easily allow their</span> users to keep authority over their data, identity, and privacy. | |||
There was a problem hiding this comment.
This looks good to me. I'm also fine with @melvincarvalho's tweak to broaden it to applications in general.
There was a problem hiding this comment.
| <span class=new>The scope of the Working Group is to define a web protocol that client-side applications can use to authenticate users and store their data with user-chosen identity and storage servers. Applications that use this protocol can more easily allow their</span> users to keep authority over their data, identity, and privacy. | |
| <span class=new>The scope of the Working Group is to define a web protocol that client-side and server-side applications can simultaneously use to authenticate users (via user-chosen identity providers, known as `IdP`s) and store their data (via user-chosen storage providers). Applications that use this protocol can more easily allow their users to exert and maintain authority over their data, identity, and privacy, by treating all of these as loosely coupled to each other, to the users, and to the applications. Such applications will be able to present data stored by multiple users in multiple data storage spaces.</span> |
There was a problem hiding this comment.
I quite like @TallTed's version. If we want to keep something closer to the original sentence, I would suggest at least s/allow/respect/ since it is the user deciding where their data gets stored, not a decision of any of the applications the user currently chooses to access the user's data with.
There was a problem hiding this comment.
The scope for defining such a web protocol doesn't need to tie itself to identity providers for authenticating users, which typically rely on third parties. I suggest not constraining the scope in this way to allow different approaches and to make the protocol specification more adaptable and flexible.
+1 to @jyasskin 's suggestion, -1 to @TallTed 's suggestion.
There was a problem hiding this comment.
[@csarven] typically rely on third parties
That's a historical perspective, and need not play a part in the design being contemplated here. User-chosen identity providers are (or should be, or at least could be) rather different beasts than service-provider-imposed identity providers.
I might suggest you take a look at the current work of the WICG and the FedID CG.
There was a problem hiding this comment.
@csarven -- Your text is most obviously read as two phrases, "(authenticate users and store their data) (with user-chosen identity and storage servers)". Rather than "[implying] a separation between the concepts of identity and storage servers", it makes it seem that user authentication and data storage is one thought, as is "identity and storage server(s)".
My suggestion is meant to make plain that authenticating users with user-chosen identity servers, and storing user data on user-chosen storage servers, are separate, loosely-coupled actions which can be provided by/through a single entity (as is typical today, though not necessarily by user choice, as it is typically the only option) which which also can be provided by distinct entities at each layer/point-of-service (as is not typical today).
The last part is the key innovation of Solid — the loosely-coupled architecture that allows a user to authenticate via their choice of identity provider, store their data on their choice of storage server, and run their choice of apps, whether on their client-device or a chosen app server, blending data that is stored on their server with data that is stored on the servers chosen by other users in their network (whether social, business, family, or otherwise).
There was a problem hiding this comment.
What definition of "identity provider" are you using towards authentication? ( https://en.wikipedia.org/wiki/Identity_provider or referenced therein? https://fedidcg.github.io/FedCM/#idp ? ... ) and which classes of authentication systems does it include and exclude?
There is no point in throwing "identity provider" into the charter (scope) if folks only really want particular specifications or category of authentication systems. Just say exactly what you want in that case instead of beating around the bush.
My point still stands that the suggestion to use "identity provider" is only constraining where that constraint wasn't intended to begin with.
Let me also point out that the Solid CG did in fact review authentication systems in the context of scope:
and the agreement was to omit explicit mention of mechanisms. The slip with IdP, RP etc. seems counter to me.
Here is also a snippet (from the minutes linked above) that is forward looking:
- TBL: It has moved steadily. Stability of the Solid OIDC is important. If we think of moving from Solid OIDC like HTTPSignatures where you have public keys.. like we had with WebID-TLS would be a lot simpler and lot more powerful and secure. So I think if we move, it is worth considering moving to two where we experiment with completely different public-key based rather than HTTP redirect based.
The agreement to not constrain the scope was alone made in the context of Solid WG charter. That alone should suffice for the PUMPKIN WG and that the text in this PR should at least reflect that view or thereabouts. If the original intention isn't conveyed in this PR's text or your suggestion, then we can revise.
There was a problem hiding this comment.
I'm not trying to say that any (existing or theorized, individual or category of) identity or authentication system is a predetermined winner nor suitable for all use cases; hence the (in my mind) generic "Identity Provider (IdP)".
If changing that to "Identity Servers (IdS)" (which is not yet described on Wikipedia/DBpedia) will pass your review, where "Identity Providers (IdP)" seems not to, I'm OK with that change.
My language is meant to make plain that this is not about a bundle of identity and storage services, probably from one provider, of which a user currently must choose all-or-none, and from which they might be able to export their data but such exports may not be in a user-usable/service-migratable form; but rather about a pool of identity services and a pool of storage services, each pool comprised of offerings from multiple providers, of which a user can mix-and-match (and change from/to) as they like.
There was a problem hiding this comment.
Okay. What I'm saying is that the use of "identity provider" isn't as generic as implied. Introducing terminology that limits the intended meaning takes us in a different direction.
Can we focus on refining the original intention given the insight, context, and reference rather than interpreting or making better sense of potentially faulty text?
What passes "my review" is what was intended / consensus.
The issue isn't about better expressing "Identity Providers" with something like "Identity Servers". I prefer not to rehash what "identi*" implies here, but as mentioned, "provider," while not always, generally suggests a third party - an entity other than the agent with which the identity is associated. This relates to who ultimately holds the highest technical and often social authority over the "identi*" (at least according to AWWW). This cuts through some of the core concerns about the user's actual agency at the end of the day.
Authentication doesn't boil down to using generic "identity providers". Example: We didn't need a "provider" with WebID-TLS. It ultimately relied on the user showing their cert on the client-side without any hops or checks through an "identity provider". Yes, a resource server for WebID Profile Documents is used, but that's beside the point (since other systems also use a server to present a description as well.)
And again, I'm not referring to presenting a variety of identity providers or services for the user to choose from at sign-in. (I don't care about that, and as I understand it, the consensus is to move away from that any way.)
That said, authentication is not always identity-centric either.
I think I've made myself clear on this topic but let me know if I can clear anything further. Handing this particular thread off to @pchampin and others... until there is new information that needs to be evaluated.
There was a problem hiding this comment.
I reported a few of the changes suggested by @TallTed in 59c37f3.
I sympathize with @csarven's concern about "identity provider" and "relying parties". I also have issues with "loosely coupled to each other, to the users, and to the applications". I'm not sure what "to the users" means in this context...
|
Can we still clarify what client-side applications means here, and can we say applications instead? |
|
If the following can be acknowledged / agreed upon, then I don't categorically have an objection to removing "client-side":
I think it is clear enough in the most common understanding of the term, i.e., an application running on the web browser. And that's already fairly clear as per Solid Protocol and the Fedora API specifications. But would replacing "client-side applications" with something along the lines of "applications running on the web browser" clarify?
Let me quote a wise person:
So, right ;) "client-side applications" meets that better than just "applications". But let's back up for a second. Instead of "clarifying" and sacrificing precision by using "client-side," did you intend to avoid limiting the scope (as I've argued earlier) to just client-side applications and so allowing for the possibility of other types of applications? For example, were you hoping to broaden the scope to include "server-side applications"? An authorization-agent perhaps among other other things as far as what an "application" might entail? If not, can you clarify? If so, do you generally agree with me to not overly constrain the scope? |
|
For me, the mention of "client-side application" is there to emphasize that the servers in the Solid ecosystem (storage server, but also the authentication server, identity server, when applicable) are application-agnostic. All the application-specific logic is in the client. I think that is an important feature of Solid/PUMPKIN, and deserved to be communicated explicitly. On the other hand, I appreciate that "client-side app" can easily be read as "in-browser app", which would be an undesirable restriction of the scope. In my view, the client can also be a native mobile or desktop app, a headless app running in the background on behalf of the user... So if "client-side" might also be misleading here. My position is that, strictly speaking, "client-side" is accurate and explicit, so I'm leaning towards keeping it. During today's meeting @elf-pavlik indicated that he could live with that. @csarven are you ok as well with keeping "client-side" (since you reacted to this particular point)? |
|
Could we replace client-side with third-party? |
|
To my mind, "third-party" conveys more about the app's origin than where it runs. "client-side" conveys more about where it runs, than where it originated. "Client-side" says to me, it runs on my local device. "Server-side" says, it runs on some other device (in the LAN, or WAN, or cloud, etc.).... |
With this interpretation, we should not use client-side since solid clients/apps can run locally on a user's device as well as remotely, including in the cloud. There are existing solid clients written in Java that run a remote machine and bots written in nodejs. As I understand the intention, it is not about specifying where solid clients/apps should or should not run. Instead, we want to clarify that clients/apps must use solid/pumpkin protocols to communicate with solid storage (resource server) rather than using some internal interface and being co-located in the same security domain. If not third party we should look for another term that empathizes the boundary between clients/apps and (resource) servers. We also don't need to look for a single word, we can say applications and add a complete sentence to capture:
We can move it to a separate PR to not hold this one back. |
There was a problem hiding this comment.
Suggesting "application" because the rest of the paragraph talks about application (generally desktop, mobile or Web application), some user controlled software application that is designed for a specific purpose.
The purpose is the make it so that user applications (as opposed to focusing on generic clients or User Agents or Web browsers in particular) can use the protocol to meet some social/personal/community needs.
Furthermore, the closest terminology from Solid Protocol is Solid app and HTTP client (by RFC). Here the context is about Solid app, and it was always about "applications". Random background:
- https://www.w3.org/DesignIssues/CloudStorage
- http://gdac.uqam.ca/WWW2016-Proceedings/companion/p223.pdf
- https://github.com/solid/user-stories
Emphasis being on users and applications.
Fedora API uses client with reference to essentially HTTP client and LDP client. There is less or no emphasis on "user" or "application" per se.
I can also see just "client" (instead of "application" or "client-side application") working, and wouldn't be opposed to that, but "application" is fine.
Not in favour of introducing new terms at this hour, e.g., "third-party".
Co-authored-by: Sarven Capadisli <[email protected]>
|
+1 to csarven suggestion above; since all proposed qualifications of applications raise concerns, I'd rather go with "application" at this point. |
suggested by @jyasskin in https://github.com/solid/solid-wg-charter/pull/69/files#r1529416046
Conversation copied below:
@jyasskin
I think "define a web protocol ... allowing users to keep authority over their data, identity, and privacy." skips an important intermediate step. In particular, the protocol itself can't allow users to do anything. Instead, it helps application developers make some choices that are better for users.
@timbl
a) It is an internet protocol. (what is a web protocol? an internet protocol based on HTTP? ok) I have always used "internet protocol" defined as the syntax and semantics and sequence of communication between different hosts on the Internet. HTTP, FTP are internet protocols Solid is a more powerful one based on HTTP.
b) The protocol design gives you value. It provides things which are true if you follow it. If you use HTTP, .. eg ..you never don't overwrite other people's changes to a resource, caches work, and so on.
If you use Solid correctly you get these properties.
and so on. When we charter the group in a way the most important thing may be that we are chartering it to provide those beneficial properties of the Solid ecosystem built on top of the Solid Protocol as a new platform
@elf-pavlik
I wouldn't formulate it this way. It is the user who allows and denies applications access to specific data at will. On the one hand, applications are the most crucial part responsible for UX, but on the other hand, they are the least trusted and privileged part of the ecosystem.
The original sentence captures it better: The protocol itself allows the user to retain authority over their data.
@melvincarvalho
The architecture of the ecosystem places pod providers at the apex of trust and privilege, following a federated model. This is not theoretical, we have witnessed it over and over in the federated model.
Subsequently, identity providers operate within a trusted third-party framework. Again this has brought centralization power to large centralized players on the web (typically email providers, which is a reason that login with email URIs is pushed so aggressively, often to the exclusion of all else).
It's worth noting that the previous integration of WebID-TLS offered more user agency, allowing sever-side support without compromising functionality. The addition of OIDC, despite initial assurances of coexistence, unfortunately led to the quiet deactivation of WebID-TLS, on the server side, a move that seems to lack a technical rationale. When the OIDC folks removed WebID-TLS from the client side, they quietly removed it from the server side, without any mandate to do so. Turning back on WebID-TLS on the server side, which should never have been removed, would help improve this situation.
This decision underscores the inherent risk of optionality in technology standards, where political dynamics may influence technical decisions, another reason why it's important to have a well defined identity system based on web protocols ie HTTP URIs, at least at this point, and not open the door to optionality in identity, in the WG, which can quickly become political.
In short, despite the wording in the charter, the user is in 3rd place in terms of agency. The pod owner is first, and has complete authority, including to cancel any user. The identity provider then has power over the user, can impersonate the user, can silently track all user activity. After that the user can add permissioned access control. This is very useful and can lead to a web operating system, but that's not quite what's communicated in the charter, at this point.
@TallTed
Doesn't really exist. It's login with email addresses. Yes, those addresses are trivially converted to URIs (by prepending the
mailto:scheme), but without that conversion, they remain addresses. Referring to them as "email URIs" does no-one any favors.@cwilson
I think my biggest concern here is buried in "if you use Solid correctly". That's not just if the user uses Solid correctly - it's relying on all app developers and other participants in the ecosystem to honor an (implicit?) pattern.
@melvincarvalho
Excellent point. If the original web was "used correctly" many of the pervasive issues we see today would not exist.
Solid's app model, right now, is not incentivized. Adverts can be blocked. What is the incentive to use solid "correctly" for app makers? The incentives are more aligned to couple apps and server together, and track users. As someone that works with advanced client side apps every day, I can say it's extremely challenging for any apps to get any sustainable revenue. In a competitive app market most of the apps will not cover their costs, leading to some dominant players, if at all. Even more importantly there is the "king maker" effect. In short, there are incentives missing for solid to be "used correctly". As the app ecosystem matures, this will become more apparent. For example how would you do advertising on a solid app, when it's easy to remove?
I think what's missing in the list is not the loose coupling of apps (this exists today elsewhere), but rather the power of apps working together on client and server side. I think the idea of a web operating system could be explained more.