Re: [OAUTH-WG] Update required for bearer token spec

2011-01-27 Thread Eran Hammer-Lahav
The bearer draft must include the registration template as done in draft-hammer-oauth-v2-mac-token section 8 including giving the name used for issuing such tokens for the token_type parameter. Every RFC must include an IANA Considerations section and your is currently in violation of -12. If yo

Re: [OAUTH-WG] Update required for bearer token spec

2011-01-27 Thread Mike Jones
Once approved, the existing names will be registered, hence no changes are needed to the bearer token draft to comply with these requirements. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, January 27, 2011 2:36 PM To: Mike Jones Cc: OAuth WG Subject: RE: Update required for

Re: [OAUTH-WG] Native Client Extension

2011-01-27 Thread Marius Scurtescu
On Thu, Jan 27, 2011 at 3:00 AM, Skylar Woodward wrote: > Marius, > > I support the extension (as per my previous letter, as I missed this thread > over the holidays) and Kiva is/was planning to support this as well.  Given > the unpredictable technology environments of many of our customers, th

Re: [OAUTH-WG] Fwd: [Technical Errata Reported] RFC5849 (2550)

2011-01-27 Thread Eran Hammer-Lahav
Verified as correct. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Thursday, November 18, 2010 6:26 PM > To: OAuth WG > Subject: [OAUTH-WG] Fwd: [Technical Errata Reported] RFC5849 (2550) > > Folks, is thi

[OAUTH-WG] some minor editorial stuff on -12

2011-01-27 Thread Brian Campbell
All in all, I like the new structure of the document. Below are a few editorial nits and questions. http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-1.4 > The diagram has "Access Grant" but it seems like the rest of the draft is now using "authorization grant" as per section 1.3? http:/

Re: [OAUTH-WG] Update required for bearer token spec

2011-01-27 Thread Eran Hammer-Lahav
-12 section 8.1 and 10.1. EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Thursday, January 27, 2011 2:10 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Your request below is ambiguous. Please provide the precise new text you're request

Re: [OAUTH-WG] Update required for bearer token spec

2011-01-27 Thread Mike Jones
Your request below is ambiguous. Please provide the precise new text you're requesting and the rationale for it. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, January 27, 2011 1:42 PM To: Mike Jones Cc: OAuth WG Subject: Update required for bearer token spec Please update

[OAUTH-WG] Update required for bearer token spec

2011-01-27 Thread Eran Hammer-Lahav
Please update the draft to comply with -12 registration guidelines and requirements asap. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft -12 feedback deadline

2011-01-27 Thread Richer, Justin P.
Overall, I much prefer the organization of this document, and I think it's going to make a lot more sense to implementers. My thoughts, per section: 1.2 "Tokens may be pure capabilities." To a non-security-engineer such as myself, this bit reads very oddly on its own. I understand that "capabil

Re: [OAUTH-WG] Native Client Extension

2011-01-27 Thread Eran Hammer-Lahav
I think it should still use the existing 'token' and 'code' values, but with a special redirect_uri value (preferably something like a urn: to make it clear). This way, there is no need to add a new mechanism for extending parameter *values* (though such an extension *can* update the registratio

Re: [OAUTH-WG] Native Client Extension

2011-01-27 Thread Richer, Justin P.
+1 on out of band auth being moved to a more fully-specified extension. It can (and likely should) still use mechanisms such as auth codes, but with different requirements such as no return URL. This is where things like the code hack can live, as well. -- Justin __

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

2011-01-27 Thread Richer, Justin P.
In an ideal world, everything that lives alongside the official oauth parameters is known to oauth, but we don't live in an ideal world and the spec needs to be able to cope with that. I can live with the relaxation here as well -- it's a reasonable compromise, though not the ideal. I'm also a

Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

2011-01-27 Thread Skylar Woodward
This is excellent. Thanks for pulling together a signature-based token spec. Some feedback: - As I think was mentioned in a previous post, this spec is also attractive as method for asserting client credentials (eg, for access token requests). Your point is noted on substituting "client_id" as

Re: [OAUTH-WG] Native Client Extension

2011-01-27 Thread Skylar Woodward
Marius, I support the extension (as per my previous letter, as I missed this thread over the holidays) and Kiva is/was planning to support this as well. Given the unpredictable technology environments of many of our customers, this flow is essential for our implementation. However, now review

Re: [OAUTH-WG] Draft -12 feedback deadline

2011-01-27 Thread Skylar Woodward
On Jan 26, 2011, at 9:09 PM, Marius Scurtescu wrote: > - 4.1. Authorization Code. It is stated that authorization code is > suitable for clients that can hold a secret. Not necessarily true, it > is the best flow for native apps, for example. We concur with this as well. Our current implementatio