Service permissions and the spec - ID & authentication: internal to spec or external?

Recently there's been much discussion about clients that seems to assume the
client will be a full-featured web browser, and that makes me a bit nervous. I
didn't imagine Open311 as having decided to use HTTP to enable straight posts
from HTTP user agents, but to facilitate rapid development.

For authentication, what if device_id were treated more like an identification
*and* access token? Perhaps all that would be needed is for read request
methods like GET /requests.[format] to take device_id as an optional argument.
If you wanted to use a fat client, you'd just need to obtain/discover the
user's ID and feed their client the appropriate device_id. All the
authentication would be encompassed within the spec -- instead of some
endpoints expecting session cookies, others expecting SSL/TLS client certs,
others maybe even expecting something like HTTP Basic Auth credentials.

It might be nice to improve this with something like Message Digest auth
implemented such that classic web clients could sign requests with client-side
JS -- but how do you all feel about the basic notion of trying to put a generic
ID & authentication mechanism into the core spec in hopes of keeping us all on
the same page?

Rest of post

Instead of creating another authentication / authorization mechanism what if
we allowed the discovery service to list what type of standard
authentication the provider requires? Then the providers can pick from a
list of ~3 standard well specified and supported authentication /
authorization mechanisms that probably have community support?

-Kam Lasater
@seekayel | @seeclickfix

Rest of post

--
http://SeeClickFix.com - User Focused Government - Report issues in the
public space, Advocate for resolution, Track the status of fixes, Connect
with neighbors.

On Fri, Aug 5, 2011 at 4:08 PM, Peter Watkins <
<email obscured>> wrote:

> Recently there's been much discussion about clients that seems to assume
> the client will be a full-featured web browser, and that makes me a bit
> nervous. I didn't imagine Open311 as having decided to use HTTP to enable
> straight posts from HTTP user agents, but to facilitate rapid development.
>
> For authentication, what if device_id were treated more like an
> identification *and* access token? Perhaps all that would be needed is for
> read request methods like GET /requests.[format] to take device_id as an
> optional argument. If you wanted to use a fat client, you'd just need to
> obtain/discover the user's ID and feed their client the appropriate
> device_id. All the authentication would be encompassed within the spec --
> instead of some endpoints expecting session cookies, others expecting
> SSL/TLS client certs, others maybe even expecting something like HTTP Basic
> Auth credentials.
>
> It might be nice to improve this with something like Message Digest auth
> implemented such that classic web clients could sign requests with
> client-side JS -- but how do you all feel about the basic notion of trying
> to put a generic ID & authentication mechanism into the core spec in hopes
> of keeping us all on the same page?
>
> --
> Peter Watkins
> City of Alexandria, Virginia
> Communication System Architect
> <email obscured>
>
>
> -----Original Message-----
> From: discuss@lists.open311.org [mailto:discuss@lists.open311.org] On
> Behalf Of Kam Lasater
> Sent: Friday, August 05, 2011 3:40 PM
> To: discuss@lists.open311.org
> Subject: Re: [Open311 Discuss] Service permissions and the spec
>
> If you set a user ID guid cookie, you can track if they are the same user
> (similar to a session cookie). Then return requests for that user. That guid
> would be the same as when someone authenticated.
>
> Would that work?
>
> -Kam Lasater
> @seekayel | @seeclickfix
>
> --
> http://SeeClickFix.com - User Focused Government - Report issues in the
> public space, Advocate for resolution, Track the status of fixes, Connect
> with neighbors.
>
>
>
> On Fri, Aug 5, 2011 at 11:39 AM, Cliff Ingham <<email obscured>
> >wrote:
>
> > Yes, and that's what I'll be doing for now. Clients can post requests
> > to the service, but when they ask for the list of requests, they'll
> > just get nothing returned.
> > -----------------------------------------
> > Full text of this topic in Open311 Discuss:
> > http://lists.open311.org/r/topic/4zq7rE7fmRWijwbmcnoJw3
> >
> > To leave Open311 Discuss, email
> > mailto:discuss@lists.open311.org?Subject=unsubscribe
> >
> > Start your own free groups and site with OnlineGroups.Net
> > http://onlinegroups.net
> >
> > Host your own online groups site with
> > GroupServer http://groupserver.org
> >
>
> -----------------------------------------
> Full text of this topic in Open311 Discuss:
> http://lists.open311.org/r/topic/1wmpAwojQ1yj9UKCuuIarB
>
> To leave Open311 Discuss, email
> mailto:discuss@lists.open311.org?Subject=unsubscribe
>
> Start your own free groups and site with OnlineGroups.Net
> http://onlinegroups.net
>
> Host your own online groups site with
> GroupServer http://groupserver.org
>
>
> -----------------------------------------
> Full text of this topic in Open311 Discuss:
> http://lists.open311.org/r/topic/vkJ9gOHlTA3v7YvxZra20
>
> To leave Open311 Discuss, email
> mailto:discuss@lists.open311.org?Subject=unsubscribe
>
> Start your own free groups and site with
> OnlineGroups.Net http://onlinegroups.net
>
> Host your own online groups site with
> GroupServer http://groupserver.org
>

The possible methods of authentication are really quite varied. Public/private
keys, HTTP Basic Auth, OAuth, OpenID, or even just a username/password sent to
a URL. Allowing multiple possibilities means all clients (such as the mobile
app) must support all possibilities to be compliant.

Would it make sense to standardize on OAuth and replace the api_key with the
OAuth token? Or perhaps there'd be the option of using either api_key or
oauth_token in each call that needs authorization.

Regardless of how we go about it, my preference would be to standardize on
OAuth. If clients need to deal with authorization to function with different
endpoints, then I think authorization should be within the scope of open311
standardization. There's also interest in evolving the spec to incorporate
more administrative functionality and that will pretty much always involve
authorization.

Perhaps it would make sense to standardize on authorization without needing
to standardize on authentication. However, this could put some pretty
web-browseresque requirements on clients to handle varied authentication
mechanisms, but I don't think I currently have enough OAuth expertise to
adequately weigh in on those nuances. I just know that OAuth is the most
established and widely implemented standard for delegating API authorization
- on mobile apps and other platforms.

Rest of post

OAuth might be popular, but it is a poor choice for apps running on customers'
hardware, as it requires the client to possess the private key associated with
the developer & application (or to provide some proxy mechanism as discussed
here: http://stackoverflow.com/questions/1934187/oauth-secrets-in-mobile-apps)
I'll grant Open311 already has this problem to an extent with the api_key. But
why dig the hole deeper?

I don't follow your logic about separating authorization and identification. To
the extent that jurisdictions have service codes that anyone can submit to,
including anonymously, there really isn't an authorization question, is there?
And to the extent that a service code requires authorization, how would you
determine that without identification?

Rest of post

--
Peter Watkins
City of Alexandria, Virginia
Communication System Architect
<email obscured>

-----Original Message-----
From: discuss@lists.open311.org [mailto:discuss@lists.open311.org] On Behalf Of
Philip Ashlock
Sent: Tuesday, August 09, 2011 10:55 PM
To: discuss@lists.open311.org
Subject: Re: [Open311 Discuss] Service permissions and the spec - ID &
authentication: internal to spec or external?

Would it make sense to standardize on OAuth and replace the api_key with the
OAuth token? Or perhaps there'd be the option of using either api_key or
oauth_token in each call that needs authorization.

Regardless of how we go about it, my preference would be to standardize on
OAuth. If clients need to deal with authorization to function with different
endpoints, then I think authorization should be within the scope of open311
standardization. There's also interest in evolving the spec to incorporate more
administrative functionality and that will pretty much always involve
authorization.

Perhaps it would make sense to standardize on authorization without needing to
standardize on authentication. However, this could put some pretty
web-browseresque requirements on clients to handle varied authentication
mechanisms, but I don't think I currently have enough OAuth expertise to
adequately weigh in on those nuances. I just know that OAuth is the most
established and widely implemented standard for delegating API authorization
- on mobile apps and other platforms.

On Mon, Aug 8, 2011 at 1:27 PM, Cliff Ingham <<email obscured>>wrote:

> The possible methods of authentication are really quite varied.
> Public/private keys, HTTP Basic Auth, OAuth, OpenID, or even just a
> username/password sent to a URL. Allowing multiple possibilities
> means all clients (such as the mobile app) must support all
> possibilities to be compliant.
> -----------------------------------------
> Full text of this topic in Open311 Discuss:
> http://lists.open311.org/r/topic/7kMd61DeaUrFIHLU2ETeVv
>
> To leave Open311 Discuss, email
> mailto:discuss@lists.open311.org?Subject=unsubscribe
>
> Start your own free groups and site with OnlineGroups.Net
> http://onlinegroups.net
>
> Host your own online groups site with
> GroupServer http://groupserver.org
>

--

--
Philip Ashlock
Open Government Program Manager | *OpenPlans.org*<http://www.openplans.org/>|
*@philipashlock* <http://www.twitter.com/philipashlock>

-----------------------------------------
Full text of this topic in Open311 Discuss:
http://lists.open311.org/r/topic/3nzxHZ2WUbqvgCdfgr35CQ

To leave Open311 Discuss, email
mailto:discuss@lists.open311.org?Subject=unsubscribe

Start your own free groups and site with OnlineGroups.Net
http://onlinegroups.net

Host your own online groups site with
GroupServer http://groupserver.org

I'd think that OAuth would supercede or replace the API key and the private
key would be per user rather than per app, so that should be better than the
status quo. I haven't followed OAuth too closely, but I think v2 attempts to
address some of the issues raised in the stackoverflow thread.

You can read up on that at:
http://hueniverse.com/2010/05/introducing-oauth-2-0/
http://tools.ietf.org/html/draft-ietf-oauth-v2-20

Otherwise, I'd think you'd just want to parallel the path that Twitter has
taken by suggesting the proxy approach with OAuth Echo and the manual token
callback approach (PIN Code):
https://dev.twitter.com/docs/auth

By separating the authorization and authentication I just meant that OAuth
defines a standard for delegating authorization without defining the
authentication mechanism (password, retina scan, etc) necessary to produce
that authorization.

The authentication question has really only come up in some of the instances
brought up by Bloomington about limiting access to view the status of issues
that have sensitive privacy considerations. I'm guessing this requirement
would be conveyed with errors in the context of the current spec, but would
likely have more friendly indicators in future versions. Authentication has
also come up in forward thinking needs for administrative features that are
not yet in the spec, eg updating the status of a request.

Phil

On Wed, Aug 10, 2011 at 9:55 AM, Peter Watkins <

Rest of post

<email obscured>> wrote:

> OAuth might be popular, but it is a poor choice for apps running on
> customers' hardware, as it requires the client to possess the private key
> associated with the developer & application (or to provide some proxy
> mechanism as discussed here:
> http://stackoverflow.com/questions/1934187/oauth-secrets-in-mobile-apps)
> I'll grant Open311 already has this problem to an extent with the api_key.
> But why dig the hole deeper?
>
> I don't follow your logic about separating authorization and
> identification. To the extent that jurisdictions have service codes that
> anyone can submit to, including anonymously, there really isn't an
> authorization question, is there? And to the extent that a service code
> requires authorization, how would you determine that without identification?
>
> --
> Peter Watkins
> City of Alexandria, Virginia
> Communication System Architect
> <email obscured>
>
>
> -----Original Message-----
> From: discuss@lists.open311.org [mailto:discuss@lists.open311.org] On
> Behalf Of Philip Ashlock
> Sent: Tuesday, August 09, 2011 10:55 PM
> To: discuss@lists.open311.org
> Subject: Re: [Open311 Discuss] Service permissions and the spec - ID &
> authentication: internal to spec or external?
>
> Would it make sense to standardize on OAuth and replace the api_key with
> the OAuth token? Or perhaps there'd be the option of using either api_key or
> oauth_token in each call that needs authorization.
>
> Regardless of how we go about it, my preference would be to standardize on
> OAuth. If clients need to deal with authorization to function with different
> endpoints, then I think authorization should be within the scope of open311
> standardization. There's also interest in evolving the spec to incorporate
> more administrative functionality and that will pretty much always involve
> authorization.
>
> Perhaps it would make sense to standardize on authorization without needing
> to standardize on authentication. However, this could put some pretty
> web-browseresque requirements on clients to handle varied authentication
> mechanisms, but I don't think I currently have enough OAuth expertise to
> adequately weigh in on those nuances. I just know that OAuth is the most
> established and widely implemented standard for delegating API authorization
> - on mobile apps and other platforms.
>
> On Mon, Aug 8, 2011 at 1:27 PM, Cliff Ingham <<email obscured>
> >wrote:
>
> > The possible methods of authentication are really quite varied.
> > Public/private keys, HTTP Basic Auth, OAuth, OpenID, or even just a
> > username/password sent to a URL. Allowing multiple possibilities
> > means all clients (such as the mobile app) must support all
> > possibilities to be compliant.
> > -----------------------------------------
> > Full text of this topic in Open311 Discuss:
> > http://lists.open311.org/r/topic/7kMd61DeaUrFIHLU2ETeVv
> >
> > To leave Open311 Discuss, email
> > mailto:discuss@lists.open311.org?Subject=unsubscribe
> >
> > Start your own free groups and site with OnlineGroups.Net
> > http://onlinegroups.net
> >
> > Host your own online groups site with
> > GroupServer http://groupserver.org
> >
>
>
>
> --
>
> --
> Philip Ashlock
> Open Government Program Manager | *OpenPlans.org*<
> http://www.openplans.org/>|
> *@philipashlock* <http://www.twitter.com/philipashlock>
>
> -----------------------------------------
> Full text of this topic in Open311 Discuss:
> http://lists.open311.org/r/topic/3nzxHZ2WUbqvgCdfgr35CQ
>
> To leave Open311 Discuss, email
> mailto:discuss@lists.open311.org?Subject=unsubscribe
>
> Start your own free groups and site with OnlineGroups.Net
> http://onlinegroups.net
>
> Host your own online groups site with
> GroupServer http://groupserver.org
>
>
> -----------------------------------------
> Full text of this topic in Open311 Discuss:
> http://lists.open311.org/r/topic/Ob7S0SVz5diq4CEXWCFVH
>
> To leave Open311 Discuss, email
> mailto:discuss@lists.open311.org?Subject=unsubscribe
>
> Start your own free groups and site with
> OnlineGroups.Net http://onlinegroups.net
>
> Host your own online groups site with
> GroupServer http://groupserver.org
>

--

--
Philip Ashlock
Open Government Program Manager | *OpenPlans.org*<http://www.openplans.org/>|
*@philipashlock* <http://www.twitter.com/philipashlock>

I'm a little worried that oAuth is solving different problems than we're
having. It might be way overkill for what we need.

With oAuth, a user can go to an application, like Facebook, and tell Facebook
that they're granting access to their account information to another
application, like, say Twitter. They set up tokens, get everything connected,
and now Twitter can connect to Facebook as that user and do stuff as them.

What we're needing is a way, in the Open311 spec, to tell clients that you must
have a user account to access certain services. Right now, I'm planning on
having users create City of Bloomington accounts with us.

oAuth seems to be solving the authenticated information sharing problem. I
just need to notify users what the rules are. (And maybe support some
federated Single Sign On).

OpenID seems like a closer match to the problems we're trying to solve.

http://openid.net

Maybe it'd make more sense if you instead thought of OAuth as a replacement
for API keys. This is what Twitter, Facebook, Google, etc have done.

On Wed, Aug 17, 2011 at 9:00 AM, Cliff Ingham

Rest of post

Actually, that's a bit misleading since Twitter, Facebook, Google apps
mostly use both an API key for the application and OAuth for users. However
it seems that there are starting to be cases where OAuth can fully take the
place of the API key. The Google URL shortener is one example:

Every request your application sends to the Google URL Shortener API needs
> to identify your application to Google. There are two ways to identify your
> application: using an OAuth 2.0
token<http://code.google.com/apis/urlshortener/v1/getting_started.html#AboutAuthorization>(which
also authorizes the request) and/or using the application's API
> key<http://code.google.com/apis/urlshortener/v1/getting_started.html#APIKey>.
> Here's how to determine which of those options to use:
>
> - If the request requires authorization (such as a request for an
> individual's private data), then the application must provide an OAuth 2.0
> token with the request. The application may also provide the API key, but
it
> doesn't have to.
> - If the request doesn't require authorization (such as a request for
> public data), then the application must provide either the API key or an
> OAuth 2.0 token, or bothwhatever option is most convenient for you.
>
>
http://code.google.com/apis/urlshortener/v1/getting_started.html#auth

On Wed, Aug 17, 2011 at 11:22 AM, Philip Ashlock <<email obscured>> wrote:

> Maybe it'd make more sense if you instead thought of OAuth as a replacement
> for API keys. This is what Twitter, Facebook, Google, etc have done.
>
> On Wed, Aug 17, 2011 at 9:00 AM, Cliff Ingham
<<email obscured>>wrote:
>
>> OpenID seems like a closer match to the problems we're trying to solve.
>>
>> http://openid.net
>> -----------------------------------------
>> Full text of this topic in Open311 Discuss:
>> http://lists.open311.org/r/topic/54AHfLAM8MmnLmQQsJchxK
>>
>> To leave Open311 Discuss, email
>> mailto:discuss@lists.open311.org?Subject=unsubscribe
>>
>> Start your own free groups and site with
>> OnlineGroups.Net http://onlinegroups.net
>>
>> Host your own online groups site with
>> GroupServer http://groupserver.org

Rest of post

In the POST Service Request....the account_id...is that the account_id of the
Open311 client system, or the Open311 server system?

Topology of Open311 systems

Open311 systems are both client and server in a directed graph of Open311
systems. For a given request, there's going to be a chain of Open311 systems
involved, as each system asks the next for more detailed, up to date
information.

For example, a person navigates their browser to FixMyStreet, which makes
Open311 requests to Bloomington, which makes requests to the Utility work order
system. Each of these Open311 servers keeps their own version of the request
data, and has their own collection of user accounts. Each of these servers
have their own rules for who gets to see what. So, if you browse to the first
server, and ask it to display data, it's going to request more detailed
information from the next server in the chain - and so on down the line.

Working authentication into the mix is a challenge. Given an authenticated
person looking at one Open311 system, how far down the line do we expect
authentication to persist?

The spec currently reads, "The unique ID for the user account of the
person submitting the request"

I think the uniqueness is meant to refer to the context of being unique
within each server, but ideally the client could reuse the same
identifier on multiple servers. However ensuring that would require it
to be globally unique and for there to be more defined requirements for
this field in the spec. If we required something like OpenID, this is
the kind of place where that would go. Since we haven't defined those
requirements, I guess this could be a username, an email address, or a
numeric user id associated with the server.

Are there any agreements or disagreements on that or thoughts on how the
documentation should better clarify anything here?

On 8/17/11 12:33 PM, Cliff Ingham wrote:
> In the POST Service Request....the account_id...is that the account_id of the
Open311 client system, or the Open311 server system?

Rest of post

You cannot post because you are not logged in.

Service permissions and the spec - ID & authentication: internal to spec or external?

Already a member?

Not a member?