Re: [OAUTH-WG] Timely review request: pre-draft-17

Almost done with -17. I have sent a few emails to the list with open questions and requests. I will include as many of the replies as I can before publishing tomorrow or Saturday. My remaining task is to try and move as much of the normative text (MUST, SHOULD) out of the security consideration

Re: [OAUTH-WG] Draft 16 Security Considerations additions

Can this be reworked to discuss the authorization endpoint specifically? The use of 'target' site is confusing. This section needs to be much more specific to the authorization process. EHL > -Original Message- > From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com] > Sent: Wednesday, Jul

Re: [OAUTH-WG] Draft 16 Security Considerations additions

" using a DOM variable (protected by JavaScript or other DOM-binding language's enforcement of SOP)" This is not clear without a reference or more details description. EHL > -Original Message- > From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com] > Sent: Wednesday, July 06, 2011 8:56 AM

Re: [OAUTH-WG] SAML Assertion Draft Items

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Brian Campbell > Sent: Thursday, July 07, 2011 12:06 PM > To: oauth > Subject: [OAUTH-WG] SAML Assertion Draft Items > > WG, > > Unfortunately I will not be at IETF#81 and will probably no

Re: [OAUTH-WG] Section 10.1 (Client authentication)

I still don’t find it useful. I think the existing text overall makes this point already. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, July 06, 2011 12:48 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: Section 10.1 (Client authentication) Hi Eran, I would su

Re: [OAUTH-WG] Native Application Text

What is ‘monitoring http headers’? EHL From: Anthony Nadalin mailto:tony...@microsoft.com>> To: "OAuth WG (oauth@ietf.org)" mailto:oauth@ietf.org>> Sent: Tuesday, June 28, 2011 6:15 PM Subject: [OAUTH-WG] Native Application Text 9. Native A

[OAUTH-WG] SAML Assertion Draft Items

WG, Unfortunately I will not be at IETF#81 and will probably not be able to post a new draft of draft-ietf-oauth-saml2-bearer prior to the I-D submission cutoff date. In lieu of that, I'd like to make a few proposals and/or ask a few questions regarding the next draft in hopes of fostering some p

Re: [OAUTH-WG] security considerations - authorization tokens

On Thu, Jul 7, 2011 at 11:08 AM, Anthony Nadalin wrote: > I was responding to the structure question only. The token text is > questionable sine the tokens are opaque to the core, seems like the token > write-up better belongs in the threat model document. Developers of the > various token specs

Re: [OAUTH-WG] security considerations - authorization tokens

I was responding to the structure question only. The token text is questionable sine the tokens are opaque to the core, seems like the token write-up better belongs in the threat model document. Developers of the various token specs and use this as guidance and reference it. From: Brian Eaton [

Re: [OAUTH-WG] security considerations - authorization tokens

On Thu, Jul 7, 2011 at 10:49 AM, Anthony Nadalin wrote: > When we constructed the current structure in Prague we thought that > structure best fit the needs of a implementer, so my preference would be to > keep it as it is now but, Torsten / Mark / Phil also may have feedback. > Really? The curr

Re: [OAUTH-WG] security considerations - authorization tokens

When we constructed the current structure in Prague we thought that structure best fit the needs of a implementer, so my preference would be to keep it as it is now but, Torsten / Mark / Phil also may have feedback. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ie

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Wednesday, June 01, 2011 11:43 AM > Throughout the document, the various parameters (e.g., client_secret and > client_id) are essentially undefined. There is no te

Re: [OAUTH-WG] security considerations - authorization tokens

Looking back at the archives, I didn't find any replies to this proposal. Torsten / Mark / Phil - is this a change you would like me to make? EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Brian Eaton > Sent: Sunday, May 22, 2011 8:

Re: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error Registry

#11: 10.3. The OAuth Extensions Error Registry Changes (by barryleiba@…): * status: new => closed * resolution: => wontfix -- +--- Reporter: Eran Hammer-Lahav |Owner: Type: s

Re: [OAUTH-WG] [oauth] #10: 8.4. Defining Additional Error Codes

#10: 8.4. Defining Additional Error Codes Changes (by barryleiba@…): * status: new => closed * resolution: => wontfix -- +--- Reporter: Eran Hammer-Lahav |Owner: Type: sugges

Re: [OAUTH-WG] Example tokens

That's not the point. Developers who are going to self-encode tokens don't need the examples. EHL From: George Fletcher [mailto:gffle...@aol.com] Sent: Thursday, July 07, 2011 6:35 AM To: William J. Mills Cc: Eran Hammer-Lahav; Brian Campbell; Oleg Gryb; OAuth WG Subject: Re: [OAUTH-WG] Example

Re: [OAUTH-WG] [oauth] #14: Restoring Client Assertion Credentials to the framework specification

#14: Restoring Client Assertion Credentials to the framework specification Changes (by barryleiba@…): * status: new => closed * resolution: => fixed Comment: Assertions document added as WG item. -- +--- Reporter

Re: [OAUTH-WG] [oauth] #13: Description of how native applications can use OAuth 2.0

#13: Description of how native applications can use OAuth 2.0 Changes (by barryleiba@…): * status: new => closed * resolution: => fixed Comment: Text provided and incorporated. -- +--- Reporter: Tony Nadalin

Re: [OAUTH-WG] [oauth] #7: Incorporate Security Considerations draft into OAuth base

#7: Incorporate Security Considerations draft into OAuth base Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- +--- Reporter: Barry Leiba |Owner:

Re: [OAUTH-WG] Timely review request: pre-draft-17

On Thu, Jul 7, 2011 at 4:01 AM, Eran Hammer-Lahav wrote: > -17 will be published by Friday at which point I will leave it to > the chairs to decide if they still want to initiate WGLC or give > the draft a few days of informal review. Working-group last call can cover all reviews of this. It's a

Re: [OAUTH-WG] Example tokens

+1 If the system just needs a random identifier with state maintained on the server, then the current tokens are fine. For those systems that plan to encrypt data in the scopes (or use JWTs) they will be much larger. Thanks, George On 7/7/11 9:24 AM, William J. Mills wrote: Access tokens rea

Re: [OAUTH-WG] Example tokens

Access tokens realistically may be longer as they may have encrypted scopes and such. From: Eran Hammer-Lahav To: Brian Campbell ; Oleg Gryb Cc: OAuth WG Sent: Wednesday, July 6, 2011 8:53 PM Subject: Re: [OAUTH-WG] Example tokens Does that apply to access t

Re: [OAUTH-WG] state parameter and XSRF detection

Allowing any flexibly in the redirection URI is a bad thing and the latest draft (pre -17) clearly states that. The main fear is that by allowing the query to be changed dynamically, attackers can find open redirector loopholes to abuse. I really wanted to make registration of the absolute URI a

Re: [OAUTH-WG] Timely review request: pre-draft-17

I finished the major part of -17, adding a new Client registration section and folding client authentication into it. This new text attempts to directly address: * client authentication requirements * define client types with regard to keeping secrets * set registration requirements * properly e