Re: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

Hi Julian, I'm glad to hear that you're not disagreeing with the decision to disallow '\' in certain parameter values. I think that knowing that brings us much closer to resolution on this issue. I'm puzzled by your statement "What I'm disagreeing with is writing the ABNF in a way that will m

Re: [OAUTH-WG] OK to post OAuth Bearer draft 15?

Thanks for your comments, Mark. Here are my thoughts on the issues that you see as being outstanding. I'd also welcome additional input from the working group on these topics: ON THE URI QUERY PARAMETER METHOD: It seems like your objection to this is based on it using a standard query parame

[OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -15

Draft 15 of the OAuth 2.0 Bearer Token Specification has been published. It contains the following changes: *Clarified that form-encoded content must consist entirely of ASCII characters. *Added TLS version requirem

[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-15.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Protocol: Bearer Tokens Author(s) : Michael B. Jones

Re: [OAUTH-WG] Mandatory-to-implement token type

On 12/18/2011 07:00 PM, Barry Leiba wrote: Closing out this issue: 7.2 Access Token Implementation Considerations Access token types have to be mutually understood among the authorization server, the resource server, and the client -- the access token issues the token, the resource server va

Re: [OAUTH-WG] Mandatory-to-implement token type

Closing out this issue: > 7.2 Access Token Implementation Considerations > > Access token types have to be mutually understood among the > authorization server, the resource server, and the client -- the > access token issues the token, the resource server validates it, and > the client is require

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

To close out this issue: There's disagreement about whether this proposed text is "necessary", but no one thinks it's *bad*, and I see consensus to use it. Eran, please make the following change in two places in the base document: > OLD > The authorization server MUST support TLS 1.0 ([RFC2246]),

Re: [OAUTH-WG] OK to post OAuth Bearer draft 15?

> Unless I hear a “no” from Mark, the chairs, or Stephen I’ll plan to publish > -15 over the weekend.  (Or if I hear a “yes”, I’ll do so right away. J) In general, I always prefer that people have the latest text to review and comment on, and when there are significant updates to distribute, a new

Re: [OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)

On 18 December 2011 17:22, Doug Tangren wrote: > > On Sun, Dec 18, 2011 at 12:05 PM, Melvin Carvalho > wrote: >> >> Is this kind of flow possibly with OAuth 2.0, and if so whose >> responsibility is it to maintain the list of agents than can access >> the resource? > > The scope parameter fulfill

Re: [OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)

On Sun, Dec 18, 2011 at 12:05 PM, Melvin Carvalho wrote: > Quick question. I was wondering if OAuth 2.0 can work with access > control lists. > > For example there is a protected resource (e.g. a photo), and I want > to set it up so that a two or more users (for example a group of > friends) U1,

[OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)

Quick question. I was wondering if OAuth 2.0 can work with access control lists. For example there is a protected resource (e.g. a photo), and I want to set it up so that a two or more users (for example a group of friends) U1, U2 ... Un will be able to access it after authenticating. Is this ki