Re: [OAUTH-WG] Rechartering

No-brainer, low-hanging-fruit: 2) Token Revocation 8) User Experience Extension Don't see the point, but simple enough not to care if plenty of others want to see it included: 4) Client Instance Extension 5) XML Encoding 9) Request by Reference Now for the objectionable... 1) Dynamic Client R

[OAUTH-WG] Rechartering

Hi all, in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion. We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter. Potentia

[OAUTH-WG] [oauth] #27: Incorporate bearer "scope" character restrictions into the base spec

#27: Incorporate bearer "scope" character restrictions into the base spec This is part of the resolution of issue #26, as discussed on the mailing list: Can you please open an issue for the core spec to incorporate the scope character restrictions from the bearer spec into the core spec? The

Re: [OAUTH-WG] [oauth] #26: scope-v percent-encoding

#26: scope-v percent-encoding Changes (by barryleiba@…): * status: new => closed * resolution: => fixed Comment: Resolved on mailing list, fixed in version -10 of the draft. -- ---+--- Reporter: barryleiba@… |

[OAUTH-WG] Request to open issue restricting scope syntax in core spec

Chairs, Can you please open an issue for the core spec to incorporate the scope character restrictions from the bearer spec into the core spec? These restrictions are: scope = "scope" "=" <"> scope-val *( SP scope-val ) <"> scope-val = 1*scope-val-char scope-val-char

[OAUTH-WG] Request to close issue 26

Chairs, Can you please close issue 26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 based upon the resolution incorporated in the bearer token specification draft 10? Thank you,

Re: [OAUTH-WG] Bearer Token Last Call Comments

Thanks for the useful feedback, Justin and Amanda. Actions taken in response in draft 10 are described inline. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Ri

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

Draft 10 of the OAuth 2.0 Bearer Token Specification has been published, which incorporates consensus decisions reached since Working Group Last Call feedback. It clos

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

Minor typo: missing period at the end of the paragraph of section 2. -- Justin From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of internet-dra...@ietf.org [internet-dra...@ietf.org] Sent: Wednesday, October 19, 2011 6:46 PM To: i-d-annou.

[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-10.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

[OAUTH-WG] Status and next steps on Assertions

A few of us had a chance to meet face to face this morning at IIW 13 in Mountain View and talked a bit about the assertions document. I wanted to try and (very quickly) summarize that and also talk about the some next steps for these documents. This is partly a summary and partly a reminder of thin

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

I'm not saying we should not make URIs valid scopes.  I'm saying that I think it's confusing and unnecessary to state that scopes are URIs.  I'd be much happier if we say "The definition of scope allows URIs to be used if needed." or some such. From: Marius Sc

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On Wed, Oct 19, 2011 at 11:15 AM, William Mills wrote: >> Is this covering all characters allowed in a URI? Why >> not define scopes as a list of URIs? > I'd rather not do this because people will presume unless we add even more > text to explain it that they need to have the form scheme://host/pa

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

> Is this covering all characters allowed in a URI? Why > not definescopes as a list of URIs? I'd rather not do this because people will presume unless we add even more text to explain it that they need to have the form scheme://host/path or some such.  It's an opportunity to bloat scopes far

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-19 19:30, Marius Scurtescu wrote: On Wed, Oct 19, 2011 at 10:26 AM, Mike Jones wrote: Yes, it covers all the characters legal in URIs. Per earlier discussion on the list, scopes are not restricted to being URIs, as existing practice includes scope elements that are not URIs such a

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

I don't think defining them as URI's is helpful here. But the set must be inclusive of URI characters. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Wednesday, October 19, 2011 10:31 AM > To: Mike Jones > C

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On Wed, Oct 19, 2011 at 10:26 AM, Mike Jones wrote: > Yes, it covers all the characters legal in URIs.  Per earlier discussion on > the list, scopes are not restricted to being URIs, as existing practice > includes scope elements that are not URIs such as "email" "profile", and > "openid". All

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Yes, it covers all the characters legal in URIs. Per earlier discussion on the list, scopes are not restricted to being URIs, as existing practice includes scope elements that are not URIs such as "email" "profile", and "openid". -- Mike -Original Message---

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Marius On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke wrote: > On 2011-10-18 17:38, Eran Hammer-Lahav wrote: >> >> Space is allowed inside a quoted string and is already not allowed inside >> each scope string. >> >> EHL >> ... > > a) yes. > > b) well: > >   The value of the scope parameter is