Fwd: [oauth] OAuth Charter Finalized

2009-03-01 Thread Chris Messina

FYI.

-- Forwarded message --
From: Hannes Tschofenig hannes.tschofe...@gmx.net
Date: Sun, 1 Mar 2009 15:05:38 +0200
Subject: [oauth] OAuth Charter Finalized
To: Alexey Melnikov alexey.melni...@isode.com, Lisa Dusseault
lisa.dussea...@messagingarchitects.com, chris.new...@sun.com, Blaine
Cook rom...@gmail.com
Cc: oa...@ietf.org

Hi Lisa, Alexey, Chris,

We have concluded our OAuth charter discussion on the mailing list.  The
charter text can be found below.

Ciao
Hannes  Blaine

---

Open Authentication Protocol (oauth)

Last Modified: 2009-03-1

Chair(s):

TBD

Applications Area Director(s):

Chris Newman chris.new...@sun.com
Lisa Dusseault l...@osafoundation.org

Applications Area Advisor:

TBD

Mailing Lists:

https://www.ietf.org/mailman/listinfo/oauth

Description of Working Group:

OAuth allows a user to grant a third-party Web site or application access to
their resources, without necessarily revealing their credentials, or  even
their identity. For example, a photo-sharing site that  supports OAuth would
allow its users to use a third-party printing Web site to access  their
private pictures, without gaining full control of the user account.

OAuth consists of:
  * A mechanism for exchanging a user's credentials for a token-secret pair
which can be used by a third party to access resources on their behalf.
  * A mechanism for signing HTTP requests with the token-secret pair.

The Working Group will produce one or more documents suitable for
consideration as Proposed Standard, based upon draft-hammer-oauth-00.txt,
that  will:
  * Improve the terminology used.
  * Embody good security practice, or document gaps in its capabilities, and
propose a path forward for addressing the gap.
  * Promote interoperability.
  * Provide guidelines for extensibility.

This specifically means that as a starting point for the working group OAuth
1.0 (draft-hammer-oauth-00.txt) is used and the available extension  points
are going to be utilized. The WG will profile OAuth  1.0 in a way that
produces a specification that is a backwards compatible profile,  i.e. any
OAuth 1.0 and the specification produced by this group must support a basic
set of features to guarantee  interoperability.

Furthermore, OAuth 1.0 defines three signature methods used to protect
requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on
new signature methods and will describe the environments  where new security
requirements justify their usage. Existing signature methods will not be
modified but may be dropped as part of the backwards compatible profiling
activity. The applicability of existing  and new signature methods to
protocols other than HTTP will be investigated.

The Working Group should consider:
  * Implementer experience.
  * The end-user experience, including internationalization.
  * Existing uses of OAuth.
  * Ability to achieve broad implementation.
  * Ability to address broader use cases than may be contemplated by the
original authors.

The Working Group is not tasked with defining a generally applicable HTTP
Authentication mechanism (i.e., browser-based 2-leg scenerio), and  should
consider this work out of scope in its discussions.  However, if the
deliverables are able to be factored in such a way that this is a
byproduct, or such a scenario could be addressed by additional future work,
the Working Group may choose to do so.

After delivering OAuth, the Working Group may consider defining additional
functions and/or extensions, for example (but not limited
to):
 * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0.
 * Comprehensive message integrity, e.g.,
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html.
 * Recommendations regarding the structure of the token.
 * Localization, e.g.,
http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/sp
ec.html.
 * Session-oriented tokens, e.g.,
http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html.
 * Alternate token exchange profiles, e.g.,
draft-dehora-farrell-oauth-accesstoken-creds-00.


Goals and Milestones:

Apr 2009Submit 'OAuth: HTTP Authorization Delegation Protocol' as
working group item
(draft-hammer-oauth will be used as a starting point for further
work.)
Jul 2009Start of discussion about OAuth extensions the group should work
on
Oct 2009Start Working Group Last Call on 'OAuth: HTTP Authorization
Delegation Protocol'
Nov 2009Submit 'OAuth: HTTP Authorization Delegation Protocol' to the
IESG for consideration as a Proposed Standard
Nov 2009Prepare milestone update to start new work within the scope of
the charter

___
oauth mailing list
oa...@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



-- 
Chris Messina
Citizen-Participant 
  Open Web Advocate-at-Large

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable 

[oauth] Re: OAuth FAIL

2009-03-01 Thread Martin Atkins


One I encountered recently:

The OAuth spec doesn't define how to generate the signature for HTTP 
requests with bodies that are not application/x-www-form-urlencoded.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
OAuth group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---



[oauth] Re: Supported Java ME versions for the OAuth Java library

2009-03-01 Thread dfoiles


Thanks Sean!

On Feb 28, 6:36 pm, Sean Sullivan s...@seansullivan.com wrote:
 I've been using the OAuth Java library on Android 1.0 but I haven't
 tried it on Java ME (J2ME).

 By the way, Simon King wrote an OAuth library for J2ME:

    http://github.com/simonpk/j2me-oauth/tree/master

 Sean



 On Sun, Mar 1, 2009 at 4:45 AM, dfoiles doug.foi...@pobox.com wrote:

  I am wondering how I find what Java ME versions are supported for the
  OAuth Java library.  And of course this is related to the consumer
  side processing.  I apologize if this has already been posted but I
  have just not been able to find it.  Also curious as to what areas of
  the consumer code is susceptible to compatibility issues for java
  based mobile platforms.  Any guidance would be greatly appreciated.- Hide 
  quoted text -

 - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
OAuth group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---