Re: [Ace] Review of draft-ietf-ace-oauth-authz -12

Samuel Erdtman <samuel@erdtman.se> Thu, 21 June 2018 15:15 UTC

Return-Path: <samuel@erdtman.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 A9D95130EA4 for <ace@ietfa.amsl.com>; Thu, 21 Jun 2018 08:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
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 fOu4C4vPvHdd for <ace@ietfa.amsl.com>; Thu, 21 Jun 2018 08:15:22 -0700 (PDT)
Received: from mail-pl0-x241.google.com (mail-pl0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) (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 471A51292AD for <ace@ietf.org>; Thu, 21 Jun 2018 08:15:22 -0700 (PDT)
Received: by mail-pl0-x241.google.com with SMTP id o18-v6so1168220pll.12 for <ace@ietf.org>; Thu, 21 Jun 2018 08:15:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EQi2QInT+ObkTAF11Fq3VKN6p+9uMwfov6UqQxvjTK4=; b=2OowmwkbQti4hRvd3CzX5KHvxJl26zfa1781HTDS8ip1OrG+rGaDitBMQUFYYQAOdY jVezThxSecPqZzYHzNfGPCfTxFLUI5xjuWVo6i3D8TKoafpCPQRh+f2NVzohQokbWDVd BOY9QdDRaGLv8IcdIQGCxa81J+lrTOXDRmdppFeFot9v7sdsfDdGgw4la4udJ3KnHNkr aLiOJyWdXAU/8qwbfRlzstnB1DrCrMif1FUCSqiE3YVujLKEuM86zP40Ats/kTRwwW5S SLq6jqUwoyT2ZvW2ivol2aWCHtmzM77SEDKD6bdd+c9rAriOe+v/rhOf4uf1QZeRVQhr nPfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EQi2QInT+ObkTAF11Fq3VKN6p+9uMwfov6UqQxvjTK4=; b=AXwm/8DREgfC2CC97v+ZtQABZRquSjbPRcensqlQjMfUZA4lhNcfE59jwXTfp+MeS2 l4kWDWcac7hLXM905mo94bhqmuwMgXqSxdGLo30h92Yhd217PXN+wYgzzG2q1nOYVmWe r6DSJI8+L03P/biofYw28mizy/vt9ho2pIL7YrSUdBdjtIUmUp9hOyy5p64jOQ8Ny49X 7jyLhQnRZx5epdx5gek07Cl1edqHmoGZdHE96FuPLLmE6gjpfbaJDq/MGDk/9TRrBJX/ 5sNmuVU4FMVT5uyV4WtDLvZx88gntiGuMlSDsbbbTId6CRWzOi/1A1886KTbuBd3lQTL Dvmg==
X-Gm-Message-State: APt69E0LchhI5lk75zmXmYS59VOgRWAfqGDdiixf5qoi8z+pq4id+S37 7xq4id0ryL0TGzrCfRTgM5Ei7J5vmCqUjsI1CYcBMA==
X-Google-Smtp-Source: ADUXVKJEVgYXHiGkd+4Bncdq69HPGy3N/ME3XLYe/dziTJQKQE5GyqkDZM3au/fnoF9fqVAV+73F4Zk1r+emJIZQ/x0=
X-Received: by 2002:a17:902:b410:: with SMTP id x16-v6mr28685912plr.324.1529594121804; Thu, 21 Jun 2018 08:15:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:b28c:0:0:0:0 with HTTP; Thu, 21 Jun 2018 08:15:21 -0700 (PDT)
In-Reply-To: <01c601d407f8$16621ec0$43265c40$@augustcellars.com>
References: <01c601d407f8$16621ec0$43265c40$@augustcellars.com>
From: Samuel Erdtman <samuel@erdtman.se>
Date: Thu, 21 Jun 2018 17:15:21 +0200
Message-ID: <CAF2hCbbe=r7eas82UwxLeE4rxonYc3scAS7UkV73h5bFPTSnhg@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-ace-oauth-authz@ietf.org, ace <ace@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000047ed70056f2862e0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/X0yZCFZF0oEJ62Tf3KuznwtypFc>
Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz -12
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 21 Jun 2018 15:15:26 -0000

Thanks for reviewing, some answers inline

On Tue, Jun 19, 2018 at 8:05 PM, Jim Schaad <ietf@augustcellars.com>; wrote:

> Based on where I currently am, here is another review of the document.
>
> 1.  In section 4 for Figure one:  Is the term "RS Information" your term or
> an OAuth term.  When I see this I think of it as information for not about
> the RS which I do not believe is the intent.
>

No, the intent is information about the RS for the client. It is described
in "2. Terminology".
Not sure if "client information" would be preferable.


>
> 2.  In section 5.1 - I am unclear what the second paragraph is supposed to
> be doing here.  I think that you want state this different.  Rather than
> talking about the "desired resource" you may want to talk about the AS.
> That would better match the title of the section.
>

The focus could maybe be different but the text is about how to find the AS
but the method for that is quite RS focused.


>
> 3.  In section 5.1 - There is a note in this section that does not seem to
> be extremely useful.  Where is this discussion go on?  Is it still going
> on?
> I am not even sure if the statement about a common understanding of time is
> correct?  It seems that one can either add or not add the nonce as an RS
> depending on if you think you understand a common time.
>

I have not heard anything on the time discussion for a while.


>
> 4.  In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc.  Given
> the use of POP tokens, what is the reason for this draft and the text about
> client credential types?  (Put it this way.  I did not need to implement
> this for anything yet.  Why is it here?)
>

Not sure what profile you have implemented.
I-D.erdtman-ace-rpcc defines how the client can use Raw Public Key or Pre
Shared Key with (D)TLS to authenticate it self to the AS. It is not a
strange operation so you might have implemented it without thinking about
it (Ludwig kind of did). I-D.erdtman-ace-rpcc is similar to
draft-ietf-oauth-mtls that defines what was already done in the wild when
it comes to x509 certificates and client authentication.
Or you might have used default client credentials (client_id/username and
client_secret/password).

I think writing about client credentials is needed since the ACE use cases
so far has been client centric, i.e. the client is often described to
authenticate as it self to get a token and not as is common i OAuth the
user is authenticated and authorizes the client to get a token.
With that said the reference to I-D.erdtman-ace-rpcc should maybe be
removed since interest in I-D.erdtman-ace-rpcc has been very limited.


>
>
>
>
> Given 15 different introspection tokens, how do I decide which is the one
> to
> present to the AS - enumerate them?
>
> 'authorization code' vs 'decode code' grants
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>