Re: [OAUTH-WG] Dynamic Scopes

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 23 June 2018 07:43 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 6DCE9130FC7 for <oauth@ietfa.amsl.com>; Sat, 23 Jun 2018 00:43:56 -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 s2h0yYTVSvAM for <oauth@ietfa.amsl.com>; Sat, 23 Jun 2018 00:43:53 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) (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 6113B130EB5 for <oauth@ietf.org>; Sat, 23 Jun 2018 00:43:53 -0700 (PDT)
Received: from [84.158.233.58] (helo=[192.168.71.126]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1fWdD4-0003ft-P8; Sat, 23 Jun 2018 09:43:50 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-6797E039-B88C-483F-B06D-3058BDC44820"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPad Mail (15E216)
In-Reply-To: <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com>
Date: Sat, 23 Jun 2018 09:43:50 +0200
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net>
References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> <CA+k3eCQMCJv3NcSnBDKBUVcm131oMAdnbopSeAaD75acAqUMwg@mail.gmail.com> <b9e4115a-512d-3155-9023-604566d7190f@aol.com> <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com>
To: George Fletcher <gffletch@aol.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/XRCrrVsyIbBBZE_oAMiNyNcYksM>
Subject: Re: [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: Sat, 23 Jun 2018 07:43:57 -0000


> Am 22.06.2018 um 23:08 schrieb George Fletcher <gffletch@aol.com>:
> 
> I would think that the scope issued to the refresh_token could represent the category or class of authorizations the refresh_token should be able to perform. For example, the kind of transactions that can be bound to access tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe I'm not fully understanding the use case :)

Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again.

One could think about a general signing permission represented by a refresh token, but not in the high assurance level cases I‘m looking into.

Hope that helps,
Torsten.