Works for me.
From: Eran Hammer
To: William Mills ; "oauth@ietf.org"
Sent: Friday, January 20, 2012 12:32 PM
Subject: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
New text added to Access Token Scope section:
If t
This is ready for IETF LC and closes all open issues.
There is one pending question (title 'Server cret verification in 10.9') which
is non-blocking and can be resolve after LC.
Chairs - per green light from Stephen posted earlier, please push the LC
request.
EHL
> -Original Message-
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
Author(s) : Eran Hammer
D
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Stephen Farrell
> Sent: Thursday, October 13, 2011 10:13 AM
> Original list of nits:
> --
>
> - Intro: Maybe add some ascii-art showing the roles of the user, browser,
>
+1
Sent from my iPhone
On 2012-01-20, at 8:50 PM, Dick Hardt wrote:
> +!
>
> On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote:
>
>> MUST sounds reasonable
>>
>>
>>
>> Eran Hammer schrieb:
>> The current text:
>>
>>If the issued access token scope
>>is different from the o
Same response as for part I from me,
S
On 01/21/2012 01:04 AM, Eran Hammer wrote:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Thursday, October 13, 2011 10:13 AM
Suggested non-trivial clarifications:
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Stephen Farrell
> Sent: Thursday, October 13, 2011 10:13 AM
> Suggested non-trivial clarifications:
> -
>
> (1) 1.3.4 - "previously arranged" might trigge
+1 for MUST.
In addition, I suggest slight rewarding: "the authorization server MUST
include the value of the scope parameter in the response" in place of
"
the authorization
server SHOULD include the "scope" response parameter
"
I think there is one parameter, scope, right?
Igor
On
FWIW, from my p-o-v everything here is either ok,
me being dumb (the password one, I need to check),
part of some other thread, or stuff that's ok to
resolve if necessary at IETF LC or later.
So - I'd say firing away with -23 and getting this
out the door (once current threads resolve themselves
+!
On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote:
> MUST sounds reasonable
>
>
>
> Eran Hammer schrieb:
> The current text:
>
>If the issued access token scope
>is different from the one requested by the client, the authorization
>server SHOULD include the "scope" resp
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Stephen Farrell
> Sent: Thursday, October 13, 2011 10:13 AM
> List 1 - Fairly sure these need changes:
>
>
> (1) In 2.3.1 MUST the AS support both HT
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 using DANE with the non PKI options that that W
MUST sounds reasonable
Eran Hammer schrieb:
The current text:
If the issued access token scope
is different from the one requested by the client, the authorization
server SHOULD include the "scope" response parameter to inform the
client of the actual scope granted.
Ste
The current text:
If the issued access token scope
is different from the one requested by the client, the authorization
server SHOULD include the "scope" response parameter to inform the
client of the actual scope granted.
Stephen asked why not a MUST. I think it should be MUST. Any d
Since there is so much agreement and peace in the air, I would through
a little editorial query:
Would it not be better to say "the appropriate version" instead of this
somewaht lawyerish "version (or versions)"?
Igor
On 1/20/2012 3:44 PM, Barry Leiba wrote:
Added to section 1:
TLS Ve
(Strictly editorial.)
Just to make the first sentence easiery to parse, I suggest to clarify
the scope (no pan intended) of "MUST." I read it the server MUST either
process the request OR fail it. If so, maybe just inserting the word
either would do the job. I would also change punctuation
> Added to section 1:
>
> TLS Version
>
> Whenever TLS is required by this specification, the appropriate
> version (or versions) of
> TLS will vary over time, based on the widespread deployment and
> known security
> vulnerabilities. At the time of this writing, TLS
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 request
indicating an invalid scope. The authorizati
Added to section 1:
TLS Version
Whenever TLS is required by this specification, the appropriate
version (or versions) of
TLS will vary over time, based on the widespread deployment and known
security
vulnerabilities. At the time of this writing, TLS version 1.2
Thanks.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Roger Crew
> Sent: Sunday, November 13, 2011 4:19 PM
> (1) 4.1.2.1, and 4.2.2.1 both say that in the case that client_id is
> provided and invalid/unknown, the auth server MUST N
20 matches
Mail list logo
