[OAUTH-WG] Dynamic Scopes

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 18 June 2018 15:34 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80049130ED7 for <oauth@ietfa.amsl.com>; Mon, 18 Jun 2018 08:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 N2vHFAvbixzw for <oauth@ietfa.amsl.com>; Mon, 18 Jun 2018 08:34:16 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (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 472FF12872C for <oauth@ietf.org>; Mon, 18 Jun 2018 08:34:10 -0700 (PDT)
Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1fUwAQ-0003Nz-4m for oauth@ietf.org; Mon, 18 Jun 2018 17:34:06 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_76B68401-AE3F-47F9-BBA8-89094742DC2F"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Message-Id: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net>
Date: Mon, 18 Jun 2018 17:34:05 +0200
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3445.8.2)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/sKUuSHu4rPNpnzPPq4t5MsLmmug>
Subject: [OAUTH-WG] Dynamic Scopes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Mon, 18 Jun 2018 15:34:33 -0000

Hi all,

I have been working lately on use cases where OAuth is used to authorize transactions in the financial sector and electronic signing. What I learned is there is always the need to pass resource ids (e.g. account numbers) or transaction-specific values (e.g. amount or hash to be signed) to the OAuth authorization process to further qualify the scope of the requested access token. 

It is obvious a static scope value, such as „payment“or „sign“, won’t do the job. For example in case of electronic signing, one must bind the authorization/access token to a particular document, typically represented by its hash.

I would like to get your feedback on what you consider a good practice to cope with that challenge. As a starting point for a discussion, I have assembled a list of patterns I have seen in the wild (feel free to extend). 

(1) Parameter is part of the scope value, e.g. „sign:<hash_to_be_signed>“ or "payments:<payment_resource_id>" - I think this is an obvious way to represent such parameters in OAuth, as it extends the scope parameter, which is intended to represent the requested scope of an access token. I used this pattern in the OAuth SCA mode in Berlin Group's PSD API. 

(2) One could also use additional query parameter to add further details re the requested authorization, e.g. 

GET /authorize?
...
&scope=sign
...
&hash_to_be_signed=<hash_to_be_signed>

It seems to be robust (easier to implement?) but means the scope only represents the static part of the action. The AS needs to look into a further parameter to fully understand the requested authorization. 

(3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry additional data. 

Example:  

"claims": {
    "id_token": {
        "acr": {
            "essential": true,
            "value": "..."
          },
        "hash_to_be_signed": {
            "essential": true,
            "value": "<hash_to_be_signed>"
        }
    },
    "userinfo": {
        "hash_to_be_signed": {
            "essential": true,
            "value": "<hash_to_be_signed>"
        }
    }
  }

I‘m looking forward for your feedback. Please also indicated whether you think we should flush out a BCP on that topic. 

kind regards,
Torsten.