Re: [Ace] draft-ietf-ace-oauth-authz-02
Ludwig Seitz <ludwig@sics.se> Mon, 10 October 2016 08:24 UTC
Return-Path: <ludwig@sics.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 C0DD31295F0 for <ace@ietfa.amsl.com>; Mon, 10 Oct 2016 01:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se
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 MSB4A8r34ecX for <ace@ietfa.amsl.com>; Mon, 10 Oct 2016 01:23:57 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36A1129601 for <ace@ietf.org>; Mon, 10 Oct 2016 01:23:56 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id x79so114154301lff.0 for <ace@ietf.org>; Mon, 10 Oct 2016 01:23:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=ISCyidsHyqcajaI+rJuxKiOfn63xrA+1ylNfbMAnOO4=; b=fDU8ZS6qTXgv++QBa7UkKfFmPpGQDTqSAqd2j+Mrs169KwqVFTZ4OZEk6+thVnICji Gh9I78ZsGamG46CzNSN0ReOCcTHM5DaV/INaCe7pRC1RhbMMzXzgS1ADhVhkxHimzE/4 bD+Yqmw0ei2ODkMy4R0mtaeyDzmBJ9IPUi5LzI/ZKDZDcioKWWTjNjCB3/+EekXiDQKz 7Z0nap0WJN689CuOyKBvLwSNT5eyQI+KX0w6gZenS+/AyXjyS7uZqXCKegyYBM0Mhc+i Ww+uYconZIGRnXQ8KaAaK6nqfO9rM8GyeKT/PFRpMTAgOmqYab9ua+9hQLKMA1v8KtGQ 9qbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ISCyidsHyqcajaI+rJuxKiOfn63xrA+1ylNfbMAnOO4=; b=QBG9B6l/S0qg6RObgiC94sc4LkQuFcl+sIeIMLy4tLaRxXgvXxCeXb2Bbxth+5BZA8 iNO9wZT7B3C2ME4fDC+8rLUHKnIEkMTU3XdB7VugikVZASSeF1rFJTuL3xdbMSCBR1N6 Q4OZGWLXv6gqc+oOq6CptnUm7ojh35R7wlSp+ln2UjEr58ZfmP0TR3sIFtiYp0WFrp7z F0nHb466CBGzqkJbzjvdJcK41/073A0dN5Co44rK65OAyoakNVB9vLZXizNE6KwEHIvR qFBO1cdkPVM9ejN9fIxGqAREub9DED7PbGR6lzsuSJFT/ln+fLmeDr2hZLS0n0Wjx9H0 1xUQ==
X-Gm-Message-State: AA6/9RnfM2+r4atmCjyw0O3uHpVhVioGfnjLLYlJKjPa4YvRUtUYFY9ffji584ByFRx9oNML
X-Received: by 10.25.40.74 with SMTP id o71mr13445667lfo.36.1476087834539; Mon, 10 Oct 2016 01:23:54 -0700 (PDT)
Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id 84sm5902152ljf.33.2016.10.10.01.23.53 for <ace@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Oct 2016 01:23:53 -0700 (PDT)
To: ace@ietf.org
References: <DB6PR0601MB2198FA78698DEC6CDB51D275FCDB0@DB6PR0601MB2198.eurprd06.prod.outlook.com>
From: Ludwig Seitz <ludwig@sics.se>
Message-ID: <c09fe056-c23f-405e-2e17-19a09a6c7f9c@sics.se>
Date: Mon, 10 Oct 2016 10:23:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <DB6PR0601MB2198FA78698DEC6CDB51D275FCDB0@DB6PR0601MB2198.eurprd06.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030103020007010001010504"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/sblKamQxvIlRzJSR7O5rGdohOPQ>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 10 Oct 2016 08:24:01 -0000
On 2016-10-10 09:02, Somaraju Abhinav wrote: > Hi, I have been looking into this draft, which is very well written, > and I would like a clarification regarding the workflow in figure 1 > of the draft. > > This workflow is a bit different to the typical one I imagine for > constrained clients/servers. Such devices would typically be > provisioned from some kind of a commissioning tool and the tool would > also initiate the provisioning process. Therefore, would it not be > better to have a protocol flow that is not necessarily initiated by > the client device? If I understand you correctly, you are suggesting to provision either the grant or the access token during the commissioning process. Our idea was to use the client credentials grant instead (not shown in our figure 1) and have the AS decide what access tokens to grant purely based on the credentials presented by the client. This way you don't have to provision anything, except for base credentials to a client. The underlying idea is that the RO would configure access control policies at the AS during the commissioning procedure. The AS uses these to determine what kind of access tokens to grant to the client, when it requests one. You could of course also provision a long term access token to the client during commissioning (I think we mentioned that somewhere, or at least thought of it), so your proposed option 2 would also be valid, and I think they would work just as well with the rest of the framework. I would suggest to add a step before (A) then, were the RO requests an access token from the AS on behalf of the client. As for option 1, I am not sure what the advantage would be of provisioning a grant to the client as opposed to using the client credentials grant. Could you elaborate on that? Regards, Ludwig -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park, Building Beta 2 Scheelevägen 17, SE-223 70 Lund Phone +46(0)70-349 92 51 The RISE institutes SP, Swedish ICT and Innventia are merging in order to create a unified institute sector and become a stronger innovation partner for businesses and society. At the end of the year we will change our name to RISE. Read more at www.ri.se/en/about-rise
- Re: [Ace] draft-ietf-ace-oauth-authz-02 Somaraju Abhinav
- [Ace] draft-ietf-ace-oauth-authz-02 Somaraju Abhinav
- Re: [Ace] draft-ietf-ace-oauth-authz-02 Ludwig Seitz