Re: old notes ("certified pod providers")

A few comments on your document:

> On Dec 4, 2015, at 10:11, Sandro Hawke <sandro@hawke.org> wrote:
> 
> One of my long-standing concerns has been around that dropdown box in cimba that lets the user pick between rww.io and data.fm.  Who gets to decide which services are listed there?  What are users told about each one, to help them decide?

I would like to have the ability to provide my own list. For example, if I had my own website that can authenticate me to others (call it LID, OpenID, web id, or Indie Auth, doesn’t matter), then a service like cimba — to which I’m authenticated in a way that it knows what my personal URL is — could pull the list from my website. At least in principle :-) My website knows what the list should be because it knows what accounts I have where (which is a side effect of being my identity provider.)

I think that would be the right architecture because it lets the user decide, and in this case the user is always right. (This idea of “bring my URL to service provider, and then have them securely call back to my site to find out more” was one of the core ideas of LID back 10 years ago or so.) 

> Another long-standing concern has been about how we get pod providers to behave well.  How do we get them to implement the specs properly?  How do we get them to provide subdomain portability?  How do we get them to respect user privacy and autonomy?
> 
> Here's a proposal to address both these areas of concern.
> 
> The basic idea is that we have a notion of certification for pod providers.

IMHO certification is a second (or later) step. First we need to have the policy. Then we need to market it so some providers will hopefully use it. IMHO it’s unlikely a provider will adopt this policy without intending to do what it actually says; they could simply stay with their own if they didn’t want that. If they did anyway, their users would call them out on it. And only if that wasn’t effective, certification might be needed. So at this stage, I don’t think certification should be a major consideration for what we want to do here.

>  To be a certified pod provider (CPP) you have to do certain things, which basically amount to behaving responsibly. There would be some Pod Provider Certification Authority (PPCA) which coordinates the certification process and publishes the list of CPPs. That list of CPPs (along with associated metadata) would be used to populate the widget applications typically use to helps users choose a new pod provider.
> 
> Nothing in the system would prevent random people from running their own pod, or even providing pod service to the public.  They just wouldn't show up on the menu for new pods, and (depending on local laws) might not be able to legally claim they were a CPP.  Local laws might someday prevent non-CPPs from offering service to the public.
> 
> The PPCA might be W3C, or it might be something else.  TBD.  There might be fees associated with being a CPP, and those fees could fund the PPCA.   The certification process might be just filling out a legally binding form, or it might involve some kind of interview or inspection process from the PPCA.
> 
> Some possible requirements for a CPP:
> 
> - all key information in machine readable form, but also legally binding

I’m not quite understanding this point. “key” as in “important” or as in “crypto”?

> - faithfully implements some version (or versions) of the pod spec
> - uses standard data-shape for TOS, pricing, which versions implemented, etc

Would be nice, but perhaps overkill for quite some time. We could do Creative-Commons-style markup?

> - must provide 90 day notice before shutting down, changing the TOS, or raising prices (notice to be provided using appropriate pod messaging protocols, at least)

The important part, to me, is to commit to notification (comment period? approval? ..?) of key changes in the relationship. I don’t know we can mandate a particular period, as each business and circumstance is different.

> - must implement protocols (when defined) for easy service termination with migration elsewhere, without penalties or awkwardness

This is really hard to define. Perhaps we need to break this down. Here are some ideas:

1. User must be able to obtain a copy of all of “their" (a term to be defined) data under control of the service provider
2. Format of the data must be readable with commonly used tools not under control of the service provider
3. Format of the data must preserve the semantics of the data (“We don’t want PDF”). Perhaps a test would be whether the service provider can restore the user’s account to the previous state given nothing else than the export format.

This doesn’t mandate that the service provider needs to invest money in writing conversion tools to/from their competitor, but it might be enough that somebody else can.

> - must provide URL forwarding and subdomain portability after service termination for no more than 10% of the price of the service at the time of termination  (alternatively: must allow people to switch to a forwarding-only service priced at no more than 10% of their existing service)

I’d be willing to leave that out, as long as the service provider allows the user to bring their own domain.

We could also keep it more abstract by saying something like “Service provider implements functionality that allows clients (man or machine) attempting to access the closed account to determine the location of the new account”. Which may simply be a redirect, but in many cases that may not be sufficient.

> - must be non-discriminatory in providing backlinks.  (in particular, we want vocabularies to link to their competitors, and products to link to sources of reviews of those products.)

That may be a deal killer for many providers because it means they *must* link to their competitors.

> - must be clear about how their infrastructure is secured; maybe require minimums like the credit card companies do

Is this an orthogonal issue?

> - participate in good faith in a review and dispute resolution system (eg listen when people post complaints; don't create fake complaints about others)

Good.

> - maybe something about a patent defense pool

Another orthogonal issue?

> - revenue sharing with applications: perhaps 30% of revenue from each user gets given to apps that user uses, under user control and defaulting to some "fair” formula

That may not apply here?

> That's the basic idea.   It probably seems a little early to be thinking about this stuff, but I think we need to make it clear before talking to other folks who might want to provide pod services.

Cheers,



Johannes.

Received on Tuesday, 8 December 2015 22:36:01 UTC