Re: [Powerbox] New draft based on further collaboration and prototyping

On Wed, May 26, 2010 at 4:19 PM, James Salsman <jsalsman@gmail.com> wrote:

> I, for one, would feel a lot more comfortable if there was a MUST
> normative direction to provide a way for users to browse, and rescind
> at their option, all of their granted permissions, without having to
> depend on a provider's home interface.
>

Are you hoping for this to work without communicating with the provider's
server at all?  Or, are you just saying you don't trust providers to
implement a proper revocation UI and so would like to require that they
honor an API as well?  The former would be possible but technically
challenging, so I'll assume you meant the latter.

We could consider adding an API to the spec, but there are a few problems:

* As Tyler said, it's hard to design a general API for this.  We can make it
possible to list and revoke grants, but more fine-grained permission editing
would depend greatly on the type of resource.

* This adds significant complication to implementing providers.

* I worry that providers may choose to reduce complication by implementing
only the API, not a corresponding type-specific UI, and thus type-specific
permission settings won't be exposed at all.

* For some types of providers, even revocability doesn't make sense.  For
example, my demo app shows a "null contact list" provider, which provides a
contact list resource that is always empty and ignores writes.  There is no
reason to revoke a grant, and requiring revocability significantly
complicates the implementation.


On the other hand, there are a few benefits to an API, other than being a
better-defined requirement:

* The UA could provide a unified interface to see and manage all grants ever
made.

* The UA could implement automatic revocation of grants when the user
navigates away from the customer site, which I believe will end up being the
desired policy in the majority of use cases.  (Some use cases call for
long-lived grants, of course.)


Personally I lean slightly towards defining an API, but don't think it's
essential.

-Kenton