IETF Logo Mail Archive

Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 18 June 2010 06:51 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC283A6949 for <oauth@core3.amsl.com>; Thu, 17 Jun 2010 23:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.262
X-Spam-Level:
X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nfUyK-lKuH5 for <oauth@core3.amsl.com>; Thu, 17 Jun 2010 23:51:23 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id ED1E83A69B7 for <oauth@ietf.org>; Thu, 17 Jun 2010 23:51:22 -0700 (PDT)
Received: from p4fff328c.dip.t-dialin.net ([79.255.50.140] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OPVQE-0001jj-9j; Fri, 18 Jun 2010 08:51:26 +0200
Message-ID: <4C1B1766.7000701@lodderstedt.net>
Date: Fri, 18 Jun 2010 08:51:18 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Brian Eaton <beaton@google.com>
References: <AANLkTil1viRqVgwJzmq7N1W21TPeT5RuclBF5DmPvVVM@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTilRNaMzu9018HcZLb_j-vKbh4Mtl1LR_BYtnro-@mail.gmail.com> <A3F81FEE-7C52-4DD1-8261-C86FAFF3E1D5@gmail.com> <AANLkTilxAaLgOZwCDXnCvTII6Q82cCs7aajL2pxb7ij3@mail.gmail.com> <55E1F9D6-71EC-40CE-8103-790E823B8D58@lodderstedt.net> <AANLkTikAHzmtXLIL4UDd2bZbqbjgAqUYTMK5TazFnCUM@mail.gmail.com>
In-Reply-To: <AANLkTikAHzmtXLIL4UDd2bZbqbjgAqUYTMK5TazFnCUM@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 18 Jun 2010 06:51:23 -0000

Am 16.06.2010 00:35, schrieb Brian Eaton:
> On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt
> <torsten@lodderstedt.net>  wrote:
>    
>> Wouldn't it be an alternative solution, if the AS first tries to
>> authenticate the user using SPNEGO within the Web Server flow? This should
>> work in the inhouse scenario. If it fails, it can fall back to
>> username/password auth..
>>      
> This would let you skip password entry, but I think you'd still
> require user confirmation to grant the access.
>    

which is ok, if you want to involve the user in the process. So he/her 
realizes what's going on.

Otherwise, the assertion workflow would be the better choice.

regards,
Torsten.

v2.46.0 | Report a Bug | By Email | System Status