Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

Neil Madden <> Thu, 09 July 2020 10:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACEA93A080E for <>; Thu, 9 Jul 2020 03:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XH1F0l1LHK4A for <>; Thu, 9 Jul 2020 03:23:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3AA3B3A080A for <>; Thu, 9 Jul 2020 03:23:33 -0700 (PDT)
Received: by with SMTP id j4so1741496wrp.10 for <>; Thu, 09 Jul 2020 03:23:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yZ4ztLJEYozDre/D31+UBi2nqZYrqRBN26RL6NAbU0c=; b=gmcHThU/sBf/8tXiVOUsvMd2pWbZu2fpTi4yUv5k8FAzaM+EiYnVVt7UMDKs0wxig5 tS1dfVcOG5U8lTi3ygRXAHX2vCZUAzgfHpQAoTyetCZg/wx6x1mNR6DYAzAzaXkYN7lw IuG/K/cymSeX1yTEuBa/gttWXGOUCepSNTRjk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yZ4ztLJEYozDre/D31+UBi2nqZYrqRBN26RL6NAbU0c=; b=GVqM/a93UddUd2Wj8YBZkJ1oA4UkeJxqg5riHCo06KSIVriXXNVXzjLI7U8QL/OTMa ypxslcBLqSRwCJPb7PAFNnzoCNXEMjSRcNM/GfirDoqMyuGVr33QsWelMtd8lSZy9PQ/ HMElyILdZY/tygszUqdaPslwYa5RowXvjHwjDKU5UW8rJU30nOztgeuwq6UvUr+TOk5s GoH+huxfljPktvP60CNj2petqMuZJ2TM+2K9fD97tyDqB9EoQ3m83FDFRavwI4CCtHav HffSYoxCqRTbFzEFb0Zqz5UQvAof4ttrZulN/42F/6TX/qbSVna2Qdl2UgCKVja0DQEd e5XQ==
X-Gm-Message-State: AOAM532/keL7Nrvdrkgpo0oKjGTvvuQR035BRnowXx3e/q3QEXqkkqTz tLhXhs0X2tOJaTl/0Eyitr7y/feTHXzbxQ==
X-Google-Smtp-Source: ABdhPJzuj9aPJe4L0u405iyl0twGuSvEDIn9Cbn1yiaJVhM3cLTIjYSMAKcSGPZWqBoO8fX605EEqw==
X-Received: by 2002:adf:ed4f:: with SMTP id u15mr61062110wro.318.1594290212225; Thu, 09 Jul 2020 03:23:32 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 68sm4069755wmz.40.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2020 03:23:31 -0700 (PDT)
From: Neil Madden <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6E0D406C-0C32-4C03-A806-86726CD2098F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 09 Jul 2020 11:23:31 +0100
In-Reply-To: <>
To: Vladimir Dzhuvinov <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jul 2020 10:23:37 -0000

> On 9 Jul 2020, at 09:53, Vladimir Dzhuvinov <> wrote:
> On 09/07/2020 11:07, Neil Madden wrote:
>>> An AS is always free to implement the 2 step solution that you proposed and indeed it could be easier to implement with RAR in the manner you described, but I don't think it should be the prescribed approach.
>> How can an AS implement this with RAR? This is my point - there is no mechanism at all in RAR to link a transaction to any kind of prior consent. It’s not about mandating such an approach, it’s about *supporting* it at all. Every transaction in RAR is a blank slate at the moment. 
> The ability to reference an existing grant is a general problem with OAuth.
> The grant management draft has a "grant_id" parameter which can be used to reference prior consent. I suppose to reference prior consent as context only a new grant_management_mode may be needed.
> <>
> We also have OAuth Incremental Authorization, which references a refresh token:
> <>
Thanks, these are useful references. The grant_id approach could work. Incremental authZ is an interesting comparison, but in that case the new grant replaces the old one, whereas in transactional auth each grant is separate. Another potential issue is that the proof of the existing grant is only presented at the token endpoint, after the flow has completed. Although this does stop the kind of attacks I was worried about, it would be better to check this up front if possible. That’s certainly an interesting reference though, and one I hadn’t considered before in this context, so thanks for mentioning it.

I think I prefer an approach using PAR, with the following additions/modifications:

1. Ability to make PAR mandatory for approval of some scopes and/or for particular clients (determined by AS policy).
2. Ability to authorize the call to the PAR endpoint using an access token instead of client authentication.
  - AS policy can decide what type of authorization is required for a particular request: user-approved access token, client_credentials access token (i.e., current OB UK), or direct client authentication.
3. If a user-approved AT is used in step 2, then the AS MUST ensure that the same user is involved in the subsequent authorization flow.

There is precedent for step 2 - e.g., token introspection currently allows an access token instead of client authentication.

If RAR was then updated to discuss this issue in the security considerations (or elsewhere) with a reference to these features of PAR then I think I would be pretty happy with that.

— Neil