Re: [OAUTH-WG] Server cret verification in 10.9

On 1/20/12 4:46 PM, Eran Hammer wrote: > Stephen asked: > >> (13) 10.9 says that the client MUST verify the server's cert which is >> fine. However, does that need a reference to e.g. rfc 6125? Also, do >> you want to be explicit here about the TLS server cert and thereby >> possibly rule out us

Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01

On 01/23/2012 01:47 PM, S Moonesamy wrote: Minor Issues: 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for native clients wasn't comprehensible to me. I'm suspicious of any such claims because I can emulate most things a browser can do in a mobile client. Perhaps this would b

[OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01

The following is the AppsDir review performed by Tim Bray. It would be appreciated if a reply is sent to Tim Bray with a copy to the apps-discuss mailing list. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.t

Re: [OAUTH-WG] SAML Bearer Spec 09 - Refresh Clarification

Sorry, I had a section reference and link wrong in the previous message. The question/suggestion about moving some text into the "OAuth 2.0 Assertion Profile" should have referenced section 4.2 and linked to here: http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2 That mistake a

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

Resending including i...@ietf.org, per the advice of Cindy Morgan of the IESG Secretariat... -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, January 23, 2012 9:24 AM To: i...@ietf.org Cc: Julian Reschke; The IESG; oaut

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard

On 1/23/12 11:31 AM, Barry Leiba wrote: >> The IESG has received a request from the Web Authorization Protocol WG >> (oauth) to consider the following document: >> - 'The OAuth 2.0 Authorization Protocol' >> as a Proposed Standard > > There are some downrefs in this document that need to be call

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard

> The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol' >   as a Proposed Standard There are some downrefs in this document that need to be called out in the Last Call notice, which weren't.

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

On 2012-01-23 18:24, Mike Jones wrote: As editor of the Oauth Bearer spec, I believe that these comments have been well understood and considered by the working group. I do understand that the working group's consensus position is different than Julian's. See these notes documenting that thi

Re: [OAUTH-WG] OAuth specs in IETF last call

Thanks Stephen and Peter, for the clarifications. For what it's worth, I'd meant to send my note to a different alias, but now I'm glad to have heard from both of you on the remaining steps ahead as a result! Best wishes, -- Mike

Re: [OAUTH-WG] OAuth specs in IETF last call

On 1/23/12 10:11 AM, Mike Jones wrote: > FYI, the OAuth Core and Bearer specifications have reached IETF last > call status - the last step before becoming RFCs. See the following > notes from the Internet Engineering Steering Group (IESG). Well, "last step" might be a bit optimistic. :) For tho

Re: [OAUTH-WG] OAuth specs in IETF last call

On 01/23/2012 05:11 PM, Mike Jones wrote: FYI, the OAuth Core and Bearer specifications have reached IETF last call status - the last step before becoming RFCs. See the following notes from the Internet Engineering Steering Group (IESG). Not quite the last step. There may be directorate re

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

As editor of the Oauth Bearer spec, I believe that these comments have been well understood and considered by the working group. I do understand that the working group's consensus position is different than Julian's. See these notes documenting that this is the case: https://www.ietf.org/mail

[OAUTH-WG] OAuth specs in IETF last call

FYI, the OAuth Core and Bearer specifications have reached IETF last call status - the last step before becoming RFCs. See the following notes from the Internet Engineering Steering Group (IESG). -- Mike -Original Message- From: oauth-boun...@ietf.org [m

Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request

+1, sounds reasonable to me and I don't see why not. Also, it fits with current implementations that I'm familiar with. -- Justin On 01/20/2012 06:19 PM, Eran Hammer wrote: The current text: If the issued access token scope is different from the one requested by the client, the autho

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

On 2012-01-23 16:46, The IESG wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' as a Proposed Standard ... Please see my comments in

[OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.

[OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard

The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send su

Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

It doesn't disallow asking the user. The server is allowed to ignore the scope requested by the client. It can also define 'default scope' to mean 'prompt user' and document that. EHL > -Original Message- > From: Andreas Åkre Solberg [mailto:andreas.solb...@uninett.no] > Sent: Monday, J

Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

Den 20. jan. 2012 kl. 21:32 skrev Eran Hammer: > New text added to Access Token Scope section: > > If the client omits the scope parameter when requesting > authorization, the authorization > server MUST process the request using a pre-defined default value, > or fail the r