Re: [OAUTH-WG] Transaction Authorization with OAuth

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 30 April 2019 10:08 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 168E912029C for <oauth@ietfa.amsl.com>; Tue, 30 Apr 2019 03:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 eEbuF2wxUd62 for <oauth@ietfa.amsl.com>; Tue, 30 Apr 2019 03:08:37 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) (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 C72C612028A for <oauth@ietf.org>; Tue, 30 Apr 2019 03:08:36 -0700 (PDT)
Received: from [80.187.87.51] (helo=[10.158.82.179]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1hLPgf-00063x-6x; Tue, 30 Apr 2019 12:08:33 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-354EB0D8-A84B-44BF-AD60-004F980C1843"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <20190428040821.GF60332@kduck.mit.edu>
Date: Tue, 30 Apr 2019 12:08:32 +0200
Cc: Sascha Preibisch <saschapreibisch@gmail.com>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <F21CD0ED-1375-4F91-B4FA-CBBFECD33C8F@lodderstedt.net>
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> <20190428040821.GF60332@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/MyuqcKQPL9ESKPVWVqHm8QS9Qfc>
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: Tue, 30 Apr 2019 10:08:40 -0000


> Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk <kaduk@mit.edu>:
> 
>> 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.

While I agree with the need to use the typ header, I don’t see a direct relationship to my proposal as it is about specifying the intended scope of tokens but not the token format itself. Can you explain your thoughts in more detail?

kind regards,
Torsten.

> 
> -Ben