Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2

John Bradley <ve7jtb@ve7jtb.com> Sun, 15 July 2012 00:39 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B946921F85DF for <oauth@ietfa.amsl.com>; Sat, 14 Jul 2012 17:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynpwdt+s9-4x for <oauth@ietfa.amsl.com>; Sat, 14 Jul 2012 17:39:03 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B93721F85DD for <oauth@ietf.org>; Sat, 14 Jul 2012 17:39:03 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so7913347obb.31 for <oauth@ietf.org>; Sat, 14 Jul 2012 17:39:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=847ao+OAombGbLiscUNkv3Qd50vzTgxVKKK64J7cZvI=; b=iofOvI0VkfpmysC4oNXbXmmQlGhqB3banJG/CK5A5zNK6qfTY5sqsDWKCnjDZ9wY0x uf7pwwC5lm3b2qNB9ansLRwW5jdd/qpiXJuftWoXQGS6/c2GFWHP32WygYokkefZCR29 8WVdaS94TduhCAsXnkTpffF4JqHkbwSq4zQB46EeqQh/BqydBCXjsKxVH7AKes/K5KZF U4/+9EiCwZdeWvaNUV3aGEZHhwRb5q0ZpBiUFeXqUaIED7aVCgOPVeaLXdoKq0vE7TMN RHJRx1wD0onjvQuGunCpG8KvcZqRaBAqPtcWSf2fhGylw3UhuzwkEXnkQTKTITG1nQhE Hv6A==
Received: by 10.60.21.103 with SMTP id u7mr8548934oee.49.1342312783433; Sat, 14 Jul 2012 17:39:43 -0700 (PDT)
Received: from [172.17.10.155] ([66.110.180.66]) by mx.google.com with ESMTPS id u5sm10116894obk.2.2012.07.14.17.39.41 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 17:39:42 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_BBD79A4B-FEB6-4CBC-A26A-E9774F0A4D9C"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <C9826DB3-31B8-492A-8319-246235315590@gmail.com>
Date: Sat, 14 Jul 2012 18:39:39 -0600
Message-Id: <C9E33EB1-49B8-4512-B19D-F0B48761DE09@ve7jtb.com>
References: <CC259909.D103%charles_honton@intuit.com> <C9826DB3-31B8-492A-8319-246235315590@gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQn3/2DS0SIzQUxO2TiMSl6TsnHGKKVfpg2PYcyZmsdSJAkEp33tJgdEzTjgaqa7xFGJXrur
Cc: draft-ietf-oauth-v2@tools.ietf.org, "Honton, Charles" <Charles_Honton@intuit.com>, "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jul 2012 00:39:04 -0000

I am OK with that wording.  It is not a change just a clarification that may make things clearer to developers.

John B.
On 2012-07-14, at 6:18 PM, Dick Hardt wrote:

> Great suggestion Charles. I think this is a good clarification. I'll adjust the copy you sent to be what follows in a new draft published tomorrow evening (Sunday PT) unless someone objects.
> 
> -- Dick
> 
> In both sections 4.1.2.1 and 4.2.2.1:
>  
>   server_error
>        The authorization server encountered an unexpected
>        condition which prevented it from fulfilling the request. 
>        This error code is needed because a 500 Internal Server
>        Error HTTP status code cannot be returned to the client
>        via a HTTP redirect.
>   temporarily_unavailable
>        The authorization server is currently unable to handle
>        the request due to a temporary overloading or maintenance
>        of the server.  This error code is needed because a 503 Service
>        Unavailable HTTP status code cannot be returned to the client
>        via a HTTP redirect.
>  
> 
> On Jul 13, 2012, at 9:45 AM, Honton, Charles wrote:
> 
>> Just to make sure I understand…
>> 
>> If  the Authorization Server returns a 5xx,  the User-Agent will immediately display a error message.
>> 
>> If  the Authorization Server returns an error code in the redirect,  the Client can take alternative actions or appropriately message the error.
>> 
>> If this is correct, perhaps a slight change in wording will explain the lack of symmetry in the error codes. 
>> 
>> In both sections 4.1.2.1 and 4.2.2.1:
>> 
>> 	server_error
>>                The authorization server encountered an unexpected
>>                condition which prevented it from fulfilling the request. 
>> 	       Using this error code allows the Client to handle this 
>>                condition instead of the User-Agent
>>          temporarily_unavailable
>>                The authorization server is currently unable to handle
>>                the request due to a temporary overloading or maintenance
>>                of the server.  Using this error code allows the Client 
>>                to handle this condition instead of the User-Agent
>> 
>> Thanks,
>> chas
>> 
>> From: John Bradley <ve7jtb@ve7jtb.com>
>> Date: Friday, July 13, 2012 9:08 AM
>> To: Charles Honton <charles_honton@intuit.com>
>> Cc: Dick Hardt <dick.hardt@gmail.com>, "draft-ietf-oauth-v2@tools.ietf.org" <draft-ietf-oauth-v2@tools.ietf.org>, "oauth@ietf.org WG" <oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2
>> 
>> 4.2.2.1 and 4.1.2.1 are error codes that are returned to the client through the browser via a 302 redirect.
>> 
>> You can't send a 5xx error via a 302 redirect.
>> 
>> That is why those need error messages specific to OAuth.  
>> 
>> Errors not being sent via redirect use normal http error codes.
>> 
>> I thought that was clear.  Is there some general confusion on this?
>> 
>> John B.
>> On 2012-07-13, at 11:55 AM, Honton, Charles wrote:
>> 
>>> Great! Because this question has come up multiple times, perhaps the rfc could explain the use of 5xx return code in addition to error_code.
>>> 
>>> I must be missing something.  Why are  server_error and temporarily_unavailable specified in sections 4.2.2.1 and 4.1.2.1?  Is there a distinction between 5xx return code and error_code in these cases?
>>> 
>>> Chas
>>> 
>>> From: John Bradley <ve7jtb@ve7jtb.com>
>>> Date: Friday, July 13, 2012 4:04 AM
>>> To: Dick Hardt <dick.hardt@gmail.com>
>>> Cc: Charles Honton <charles_honton@intuit.com>, "draft-ietf-oauth-v2@tools.ietf.org" <draft-ietf-oauth-v2@tools.ietf.org>, "oauth@ietf.org WG" <oauth@ietf.org>
>>> Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2
>>> 
>>> FRom what I can see in a similar discussion Eran pointed out that this is a direct communication, communication between the client and token endpoint.
>>> 
>>> Server Error and temporarily unavailable are not OAuth specific and are handled by existing HTTP error codes.
>>> 
>>> I don't see a need for a change.
>>> 
>>> Unless something else dramatic comes up I would like to see draft 29 go to the RFC editor.
>>> 
>>> (Though one person mentioned to me that 30 is a nicer number:)
>>> 
>>> John B.
>>> 
>>> On 2012-07-12, at 8:09 PM, Dick Hardt wrote:
>>> 
>>>> Charles
>>>> 
>>>> Thanks for the suggestion. I just did publish a new draft that included a number of items that had been discussed and I would like to get some feedback on your suggestion before incorporating it (or not).
>>>> 
>>>> Does anyone have feedback on the change below? (+/-)
>>>> 
>>>> -- Dick
>>>> 
>>>> On Jul 12, 2012, at 1:45 PM, Honton, Charles wrote:
>>>> 
>>>>> E. Hammer, D. Recordon, D. Hardt, et.al,
>>>>> 
>>>>> I'm looking at draft 28 (http://tools.ietf.org/html/draft-ietf-oauth-v2-28).
>>>>> 
>>>>> In Section 5.2 the error code should probably include:
>>>>> 
>>>>> 	server_error
>>>>>                The authorization server encountered an unexpected
>>>>>                condition which prevented it from fulfilling the request.
>>>>>          temporarily_unavailable
>>>>>                The authorization server is currently unable to handle
>>>>>                the request due to a temporary overloading or maintenance
>>>>>                of the server.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> chas
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>