Re: [OAUTH-WG] Transaction Authorization with OAuth

Steinar Noem <steinar@udelt.no> Tue, 23 April 2019 11:19 UTC

Return-Path: <steinar@udelt.no>
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 42281120045 for <oauth@ietfa.amsl.com>; Tue, 23 Apr 2019 04:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.com
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 SPPpj2A5g8Za for <oauth@ietfa.amsl.com>; Tue, 23 Apr 2019 04:19:14 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411CB12016C for <oauth@ietf.org>; Tue, 23 Apr 2019 04:19:13 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id s24so12399653otk.13 for <oauth@ietf.org>; Tue, 23 Apr 2019 04:19:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wf30DyiLsxCdn+pmMuLMXSJsV+xO4O6M1YPHfLnDN1M=; b=irJRq5SW5zzkXWTgTT9wieSWLAgri5eAREGxCdz5WYEsRYJYTm84oZ1fH1tOx1uW+e bZQmVvyRrliiDTyMlDylw4HF+MUro9hpUPrL8/sj3JkqTM9kMFhbSIRx+SsqqfRWwmB3 p9f27XOEfV9RA3ib/7alebI7xBr/e+CeF6yuBSgbDxxBnVpLIdL/XFCM9QSANfwcTmO/ JaxRRs3hPJHVq0PQQ8q4FuOyCqG5jM5rjUHdErM/V4y8j3eDDcvRBgoiayc8ajsSwCg9 jiI9+KqLbTyOwj6/64XoNxYDFe7Y9hXoZAlB+OquK1pj7Ze0Z+5ia+gV8BjPH6jTSPFd +iGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wf30DyiLsxCdn+pmMuLMXSJsV+xO4O6M1YPHfLnDN1M=; b=eKbbIkhUuXUyf+TdjRBjMaQilHXqt3V11Dubi0vOHWvrUmQTemdykaQX9xQVpQTto/ 9XeuYmYhucQDd4wz/RDf58FNzTlt1ivIHmElyUGv5OQsJS/QCWDbO3xLNiGk6JBSgd8d gea3gTaAGh94xZ41to744wr6qpHLakJQnEOIsH5fLSjRhtYyd8z+H8ErGAQ/rLEh4q1T Gajd0Vla/hXxzV31RaJTyxFlWBkpLy/23TP9vytX7laSd+yOoP+vpu8FyK0ZNI96HeBr VuwBr/ZEpl4g8A3sM7YCRuu0oZM7dDN8RbrIfiHcUfYcPEksGZegAIh0wjUNhW+YukVj b46Q==
X-Gm-Message-State: APjAAAXPlZVKTydJksmGkSMYJZYZLPyqR+CWm1t1gRL7BDNLryynAqLL MVTzpeY07zFeualvx0DoHiyzWAPjRHJpWRyuz4I8550BNxI=
X-Google-Smtp-Source: APXvYqx71a49dziqUYWkG9rNRBScQSjoz5aG1slyp8kKRKe4fcO84XHLbslw0PeWF0ufybDJn18SIbotemw9AXrosFY=
X-Received: by 2002:a9d:5a02:: with SMTP id v2mr14684079oth.70.1556018352834; Tue, 23 Apr 2019 04:19:12 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <CAHsNOKdsdmqK3tCXGyqHtSOY3qtEjbm5UN434y6eTSAwoBiJow@mail.gmail.com> <EBDFF35E-F9F2-4696-BA05-CADF9962775B@lodderstedt.net>
In-Reply-To: <EBDFF35E-F9F2-4696-BA05-CADF9962775B@lodderstedt.net>
From: Steinar Noem <steinar@udelt.no>
Date: Tue, 23 Apr 2019 13:19:01 +0200
Message-ID: <CAHsNOKexT55Cnyyw64C3h1P2q_JKRTu24XbuLyG2TQJbXj+-9Q@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002f5bb6058730c19b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-poE0tNMIgfScXpq8JQYzdB0QRY>
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, 23 Apr 2019 11:19:17 -0000

Ah, I hadn't considered the OpenId Connect/claims connection. At one point
we actually considered using the private_key_jwt client secret to transport
"claims" from the client to the AS - so we were happy to learn about the
JAR spec.

In my opinion TLS is good enough, but some security analysts and data
protection officers in the health sector may not agree with me :)
Our main use case for OAuth is interoperability between businesses on a
national level (hospitals, primary health care etc), where a health
personel requests information about a patient in a different legal entity
(business) than where they are employed.
It's a complex domain, in certain cases the combination of two personal
identifiers can be considered sensitive alone (e.g. a psychiatrist and
patient combination). But, we have seen a "softening" of the requirements
for confidentiality - so hopefully signatures will be sufficient..

- S

man. 22. apr. 2019 kl. 18:29 skrev Torsten Lodderstedt <
torsten@lodderstedt.net>:

> HI Steinar,
>
> > On 22. Apr 2019, at 10:38, Steinar Noem <steinar@udelt.no> wrote:
> >
> > Hi Torsten, thank you for writing this clarifying article :)
>
> Pleasure :-)
>
> >
> > In the health sector in Norway we are facing similar challenges
> regarding the need for contextual information.
> > At the time, our planned solution is to package this information as
> custom claims in request objects - e.g.: “helse:client/claims/xxxx”,
>
> and do not forget: claims in a request object means you force your client
> and AS to turn on OpenID Connect for your requests (scope openid, ID Token,
> ...) even if you “just” want to authorise API access.
>
> > but after reading your article I realize that the structured scope
> approach makes a lot more sense and, as you stated in the article, pushing
> the request objects mitigates the issues with request-size and complexity
> on the client side.
> > In our case we may also have a requirement to encrypt the pushed request
> object due to potential sensitive content.
>
> TLS is not enough?
>
> kind regards,
> Torsten.
>
> >
> > - Steinar
> >
> >
> > lør. 20. apr. 2019 kl. 20:21 skrev Torsten Lodderstedt <
> torsten@lodderstedt.net>:
> > Hi all,
> >
> > I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>
> >
> > I look forward to getting your feedback.
> >
> > kind regards,
> > Torsten.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> > --
> > Vennlig hilsen
> >
> > Steinar Noem
> > Partner Udelt AS
> > Systemutvikler
> >
> > | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |
>
>

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |