Re: [OAUTH-WG] Transaction Authorization with OAuth

Benjamin Kaduk <kaduk@mit.edu> Sun, 28 April 2019 04:08 UTC

Return-Path: <kaduk@mit.edu>
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 EE7EE1200B1 for <oauth@ietfa.amsl.com>; Sat, 27 Apr 2019 21:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 x3KmcsmGwWgC for <oauth@ietfa.amsl.com>; Sat, 27 Apr 2019 21:08:27 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8AC03120048 for <oauth@ietf.org>; Sat, 27 Apr 2019 21:08:26 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3S48Laq027230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Apr 2019 00:08:23 -0400
Date: Sat, 27 Apr 2019 23:08:21 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Sascha Preibisch <saschapreibisch@gmail.com>, oauth <oauth@ietf.org>
Message-ID: <20190428040821.GF60332@kduck.mit.edu>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <CAP=vD9u8ki=WzHr-VrLZcdU4nszNja5pgkB+4n2N+-xqCrpm=Q@mail.gmail.com> <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net> <CAP=vD9sL-ESxo5obtnYCFrT4EEjeQt-0GDsqmxWFDy3+HxDN4A@mail.gmail.com> <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1CeFW92-anspmJxAMqxLmx6pWFU>
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 28 Apr 2019 04:08:29 -0000

On Wed, Apr 24, 2019 at 07:08:25PM +0200, Torsten Lodderstedt wrote:
> Hi Sascha,
> 
> I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition. 
> 
> In my last example, the scope is defined as 
> 
>    "structured_scope":{  
>       "sign":{  
>          "credentialID":"qes_eidas",
>          "documentDigests":[  
>             {  
>                "hash":
>                  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
>                "label":"Mobile Subscription Contract"
>             }
>          ],
>          "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>       },
>       "payment":{  
>          "type":"sepa-credit-transfer",
>          "instructedAmount":{  
>             "currency":"EUR",
>             "amount":"123.50"
>          },
>          "debtorAccount":{  
>             "iban":"DE40100100103307118608"
>          },
>          "creditorName":"Merchant123",
>          "creditorAccount":{  
>             "iban":"DE02100100109307118603"
>          },
>          "remittanceInformationUnstructured":"new Smartphone"
>       }
> 
> This means “sign" and “payment" would determine the scheme of the respective object. 
> 
> What do you think?

I think it reminds me of why draft-ietf-oauth-jwt-bcp recommends using the
"typ" header, and all the reasoning we have to do about different types of
tokens (not) being replayable at a different endpoint and being interpreted
wrongly.

-Ben