Re: [OAUTH-WG] Transaction Authorization with OAuth
Benjamin Kaduk <kaduk@mit.edu> Fri, 03 May 2019 01:13 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 10B4F12011C for <oauth@ietfa.amsl.com>; Thu, 2 May 2019 18:13:05 -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 lT_SSbB3qX8y for <oauth@ietfa.amsl.com>; Thu, 2 May 2019 18:13:03 -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 2220E12004D for <oauth@ietf.org>; Thu, 2 May 2019 18:13:02 -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 x431CwaM024029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 May 2019 21:13:00 -0400
Date: Thu, 02 May 2019 20:12:58 -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: <20190503011258.GM59871@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> <20190428040821.GF60332@kduck.mit.edu> <F21CD0ED-1375-4F91-B4FA-CBBFECD33C8F@lodderstedt.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F21CD0ED-1375-4F91-B4FA-CBBFECD33C8F@lodderstedt.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nM13AjG1_WxM5jrZIrJdnevStAo>
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: Fri, 03 May 2019 01:13:05 -0000
On Tue, Apr 30, 2019 at 12:08:32PM +0200, Torsten Lodderstedt wrote: > > > > 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? I'll try; my thoughts do not seem entirely well formed, though, so perhaps it will not work very well. It seems like we're opening up for the structured_scope to be an arbitrary JSON object. But the recipient needs to know what context to interpret that object in -- e.g., this "payment" subobject has a clear intent to transfer money in the indicated currency from the one account to the other. But someone else might put a different subobject under "payment", perhaps one where users "pay" each other in virtual kittens for good behavior, which is a different context but the same JSON element. Receivers will of course have some expectation of what they should be getting, and can in effect enforce that what they receive matches a schema, but those are implicit ways of indicating what context an object is to be interpreted in, and we may want to consider explicitly stating an indicator of the context in which an object is intended to be considered. Maybe there's already something in the containing message that will fill that role (see also: "not entirely well formed"), in which case this concern evaporates. Thanks, Ben
- [OAUTH-WG] Transaction Authorization with OAuth Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Transaction Authorization with OAu… Steinar Noem
- Re: [OAUTH-WG] Transaction Authorization with OAu… Pedro Igor Silva
- Re: [OAUTH-WG] Transaction Authorization with OAu… Jim Manico
- Re: [OAUTH-WG] Transaction Authorization with OAu… Pedro Igor Silva
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Pedro Igor Silva
- Re: [OAUTH-WG] Transaction Authorization with OAu… Pedro Igor Silva
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Pedro Igor Silva
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Sascha Preibisch
- Re: [OAUTH-WG] Transaction Authorization with OAu… George Fletcher
- Re: [OAUTH-WG] Transaction Authorization with OAu… Pedro Igor Silva
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Steinar Noem
- Re: [OAUTH-WG] Transaction Authorization with OAu… George Fletcher
- Re: [OAUTH-WG] Transaction Authorization with OAu… George Fletcher
- Re: [OAUTH-WG] Transaction Authorization with OAu… Sascha Preibisch
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… George Fletcher
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Sascha Preibisch
- Re: [OAUTH-WG] Transaction Authorization with OAu… Takahiko Kawasaki
- Re: [OAUTH-WG] Transaction Authorization with OAu… George Fletcher
- Re: [OAUTH-WG] Transaction Authorization with OAu… George Fletcher
- Re: [OAUTH-WG] Transaction Authorization with OAu… Brian Campbell
- Re: [OAUTH-WG] Transaction Authorization with OAu… Steinar Noem
- Re: [OAUTH-WG] Transaction Authorization with OAu… Benjamin Kaduk
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Brian Campbell
- Re: [OAUTH-WG] Transaction Authorization with OAu… Benjamin Kaduk
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt
- Re: [OAUTH-WG] Transaction Authorization with OAu… Takahiko Kawasaki
- Re: [OAUTH-WG] Transaction Authorization with OAu… George Fletcher
- Re: [OAUTH-WG] Transaction Authorization with OAu… Dave Tonge
- Re: [OAUTH-WG] Transaction Authorization with OAu… George Fletcher
- Re: [OAUTH-WG] Transaction Authorization with OAu… Nat Sakimura
- Re: [OAUTH-WG] Transaction Authorization with OAu… Torsten Lodderstedt