IETF Logo Mail Archive

Re: [Ace] WGLC for draft-ietf-ace-authz

Ludwig Seitz <ludwig.seitz@ri.se> Wed, 24 October 2018 09:03 UTC

Return-Path: <ludwig.seitz@ri.se>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF943130E7F; Wed, 24 Oct 2018 02:03:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfhBiPGlPKjy; Wed, 24 Oct 2018 02:03:09 -0700 (PDT)
Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186A8130E7E; Wed, 24 Oct 2018 02:03:09 -0700 (PDT)
Received: from 1gFF4D-000RNH-TB by out11c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gFF4D-000RR2-VL; Wed, 24 Oct 2018 02:03:05 -0700
Received: by emcmailer; Wed, 24 Oct 2018 02:03:05 -0700
Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gFF4D-000RNH-TB; Wed, 24 Oct 2018 02:03:05 -0700
Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 24 Oct 2018 11:03:04 +0200
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Jim Schaad <ietf@augustcellars.com>, draft-ietf-ace-oauth-authz@ietf.org, ace@ietf.org
References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> <e430cb24-1ac8-5eaf-2513-399c345fc999@ri.se> <20181024014450.GN45914@kduck.kaduk.org>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <b8ccf37b-7872-278c-b29a-69fe35fc4c3e@ri.se>
Date: Wed, 24 Oct 2018 11:02:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20181024014450.GN45914@kduck.kaduk.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162)
X-Outbound-IP: 194.218.146.197
X-Env-From: ludwig.seitz@ri.se
X-Proto: esmtps
X-Revdns:
X-HELO: sp-mail-2.sp.se
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Authenticated_ID:
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/uS-QT__TpHFzdurmumPL-HubPFg>
Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 09:03:11 -0000

On 24/10/2018 03:44, Benjamin Kaduk wrote:
> Just one minor note -- this is a great discussion to see happening!
> 
> On Tue, Oct 23, 2018 at 04:43:14PM +0200, Ludwig Seitz wrote:
>>
>> On 22/10/2018 21:09, Jim Schaad wrote:
>>> * Section 5.8.2 - If the RS is going to do introspection, can it send some
>>> type of "Server Busy - try again in xxx" while it does the introspection
>>> rather than just doing an ack of the request and possibly waiting a long
>>> time?
>>
>> This is probably transport protocol specific, and we were asked not to
>> link the framework to a specific protocol, thus I don't know if we can
>> provide guidance here.
> 
> I think it would be okay to say something like "some transport protocols
> may provide a way to indicate that the server is busy and the client should
> retry after an interval; this type of status update would be appropriate
> while the server is waiting for an introspection response".  Which does
> provide guidance, but in a non-normative fashion that does not require or
> prohibit any given transport protocol.
> 
> -Ben
> 

Thank you for the suggestion. I will integrate that text.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

v2.23.0 | Report a Bug | By Email