Plans for OpenFile
Adam Rosien
our recent 1.0 release.
I would like to reiterate that OpenFile's purpose is to describe a
recommended set of protocols, and necessary extensions to existing
protocols, to have a User explicitly authorize what resources are
granted to the client application. By choosing to build on OAuth,
Atom, and XRD we are in a good position to be both developer- and
company-friendly.
I would like to suggest some simplifying changes to the specification:
1. Rather than returning the URI to the Authorized Feed when the
client requests an OAuth Access Token, the Authorized Feed should
itself be the OAuth Protected Resource, and documented in the XRD
discovery document. (This implies that the Authorized Feed URI
returns different representations based on what Access Token you
supply to the request)
2. Move the client request parameters from the OAuth Authorization
Endpoint to the OAuth Request Token Endpoint. This aligns better with
the existing OAuth token extension proposal at
http://wiki.oauth.net/TokenAttributes.
Your thoughts are appreciated.
A week or two ago I posted the OpenFile spec to the OAuth Extensions
mailing list for comments. One suggestion was to help define a
request token attribute syntax to specify the ones we are proposing,
so I'll be working on that.
Outstanding items I have are:
1. In the Service Provider push scenario, where a User selects
resources to "open" in a client application, when the provider POSTs
the Authorized Feed to the Client, doesn't the Client need an Access
Token to access any links referenced in the Authorized Feed? I think
we need to define a way to include the Access Token as part of the
POST (securely, of course).
2. Working on the general OAuth request token attributes spec that
OpenFile will reference.
3. Following the XRD-Simple spec development to remain compatible with
how OAuth Discovery uses it.
4. Evangelism!
How are *you* all doing? Any news related to OpenFile?
.. Adam