Re: [OAUTH-WG] No client_id parameter in resource requests

access token values.  There is probably some security reasoning behind this that I don't understand...can someone kindly inform me?  :-). Thanks, ~pj ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Paul

Re: [OAUTH-WG] expires_at vs expires_in

/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Paul Lindner

[OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests

Hi, As I've been working through our oauth2 implementation I've noticed that it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based on the request parameters alone. Based on some investigative at the Shindig project it appears that the only standard way to to determine 1.0a vs 2.0 is

Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests

. On the authorization server, why would you use the same endpoint? EHL *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Paul Lindner *Sent:* Thursday, June 10, 2010 8:24 AM *To:* OAuth WG (oauth@ietf.org) *Subject:* [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests

Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests

Hammer-Lahav e...@hueniverse.comwrote: But in that case, all the other oauth_* parameters are missing. It's trivial. EHL -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Thursday, June 10, 2010 10:39 AM To: Paul Lindner Cc: Eran Hammer-Lahav

Re: [OAUTH-WG] the format parameter

Another alternative idea -- designate the 'format' param as an accept-header override. This technique has been successful for the X-Method-Override header and cements the Accept header syntax as the proper mechanism for selecting output format. On Thu, Jun 10, 2010 at 10:59 AM, Justin Richer

Re: [OAUTH-WG] Standardisation of a Java API

Ditto here. Apache Shindig uses OAuth extensively and we would like to upgrade it to OAuth 2.0. The current stable java oauth library is okay, but does not have an active developer community, and isn't even published to maven central. I just had a peek at Amber, looks fairly decent. I can help

Re: [OAUTH-WG] Renaming expires to expires_in?

+1 This would more closely match the nomenclature used by the oauth session extensionhttp://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html . On Mon, Apr 5, 2010 at 9:09 AM, David Recordon davidrecor...@facebook.comwrote: As one of our engineers was implementing a client,

Re: [OAUTH-WG] Next Steps

hat roles=lurker,enduser Here at LinkedIn we've been following the OAuth developments and we're all happy to see progress being made on 2.0. From our side we'd love to see standardization of a number of defacto standards we use in our implementation. Specifically the following: * OAuth

Re: [OAUTH-WG] Signatures, Why?

What about http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html ? That's in use and has been implemented in shindig for quite some time. That draft adds protection of the body -- I don't know of any draft that covers signing the headers... On Mon, Mar 15, 2010 at 11:22 PM,

Re: [OAUTH-WG] Defining a maximum token length?

Standards have size limits to overcome operational issues all the time. For an extreme example look at the backflips that MIME goes through to insure that mail can be delivered by even the most hostile relay. (Including systems using EBCDIC, and systems that mangle payloads!) If there are no

Re: [OAUTH-WG] Defining a maximum token length?

j...@jkemp.net wrote: On Mar 10, 2010, at 3:47 PM, Paul Lindner wrote: Standards have size limits to overcome operational issues all the time. Standards usually standardize on the things necessary for interoperability, and token size isn't a necessity for interoperability unless we make