IETF Logo Mail Archive

Re: [OAUTH-WG] An access token claim to identify data processing purposes

Steinar Noem <steinar@udelt.no> Mon, 04 April 2022 16:08 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 5E55C3A0B77 for <oauth@ietfa.amsl.com>; Mon, 4 Apr 2022 09:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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.20210112.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 7CrQ6pN5JS0k for <oauth@ietfa.amsl.com>; Mon, 4 Apr 2022 09:08:42 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 82BE83A08AB for <oauth@ietf.org>; Mon, 4 Apr 2022 09:08:42 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id d5so18173543lfj.9 for <oauth@ietf.org>; Mon, 04 Apr 2022 09:08:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ikPGLSJKomBMPQISb+xm4OU7Ugtc4mHG3xZcg0DCHdo=; b=DOJnNoKMTWechAKUCjwQKg/g/6wx/cS8Y0Xa1Ogmz4fGmQaqUKfmuSiOCGFT3CaPj7 vs0sojnc+PtXy43Ca6cicNsIthbuQvdFraoKvCGP9odgWoQxtG0wsmzK6xC3quxQJA2K cUBEh+9Ch2Ja0kbCM9mOfERaQtmZ4UudvHxLmzf2UOtikHJ93jU2AY9SsPXfWUzwMJFP EcmYUSRfLpVYIdHu3aZ3n7IBt+NL0XDvNj8ET6fwIHWxpLHRKF+B5wf42XSwQnpGHnim XjayJUFrfqjIrjqNUo9GuRo9bhslOByyFVkeDzndJ4hoRJRaMBKGf+72XmSyokHfGNjl qHBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ikPGLSJKomBMPQISb+xm4OU7Ugtc4mHG3xZcg0DCHdo=; b=26zzfADY1Qq96WRE6NDSnVzOSDgCz1wEByjnirt0lUp1XVnUpROV6PpFzLtNgEdKHT 7a8dnBKvdBXvw26O/HW5/1rkWBWUj6Bvd7IBej0p0xEaPWc0S4Ficjt/vbqe63r+NIRc wNBrLBlil3j3rtTIdFwsKceluRJ2ga+eXAx3KxutJ03pcwN+VVEgGfAoMft0SDAS+/x6 T62o9DtVdnSFZ9dco7DLnnQbX65/cJRR/99o08qhbWWZrdcKMtHToBQjfilPHYNlG2ib I77+p5/EdC11D9RbkZLXOmfpiFqA3w41jcH2m5wX7GDg/VxCuwwEqeZPctKhdan7tTId wYrA==
X-Gm-Message-State: AOAM530bjyu1GmTC1Yh4NaWxQwZJ/4NhTqzmOIVK/abZdgkuSYUI9AFB xm0GOtQ8GDLOh8Is7YPd3TZDeUN1ez6g2nLZOvEdHg==
X-Google-Smtp-Source: ABdhPJzrFyFZRHaRePeNtmcDofBPS4NUL7IqofG+8aUrHzAbabEbe208tPrATKnsAZoALqO/bxV1teDXTJOd5AjQFIM=
X-Received: by 2002:a05:6512:3f97:b0:44a:f67d:7d8 with SMTP id x23-20020a0565123f9700b0044af67d07d8mr124311lfa.81.1649088520095; Mon, 04 Apr 2022 09:08:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAP9qbHWPfswiPFhi4ijiYO8BcFJagWHROgBtqVZzB7zghdCzsg@mail.gmail.com> <CAHsNOKd3xe4EmhJvdGGE5V4fpq=sY0gWUvYJaGiMnVsrv7q-Dg@mail.gmail.com> <CAP9qbHVnENZwCZyygFdf0wqwE0fD_9yghV62vC4wpArSTYW9-A@mail.gmail.com>
In-Reply-To: <CAP9qbHVnENZwCZyygFdf0wqwE0fD_9yghV62vC4wpArSTYW9-A@mail.gmail.com>
From: Steinar Noem <steinar@udelt.no>
Date: Mon, 04 Apr 2022 18:08:28 +0200
Message-ID: <CAHsNOKfO7_c3Ls_cZURsG62gDGjm3bzgQA0KmVT7FPu6QqMrmQ@mail.gmail.com>
To: Roberto Polli <robipolli@gmail.com>
Cc: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000071a30e05dbd65784"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BSs8T-O9gzw9FlnW5fkqsJayZSc>
Subject: Re: [OAUTH-WG] An access token claim to identify data processing purposes
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: Mon, 04 Apr 2022 16:08:47 -0000

Ah, for machine-to-machine the eKYC/IA spec is not relevant - as it
requires an interactive session (an authenticated user).
But the Rich Authorization Spec (authorization_details) describes how to
express more information related to a grant, so that would be fitting I
would think. We use the structure for accountability purposes, legal basis
and legitimate interest - and reflect certain claims in the access token
(JWT).

man. 4. apr. 2022 kl. 18:02 skrev Roberto Polli <robipolli@gmail.com>:

> Thanks Noem,
>
> Il giorno lun 4 apr 2022 alle ore 16:32 Steinar Noem <steinar@udelt.no>
> ha scritto:
> >>  I'm looking for a standard way to express data processing purposes in
> access token/requests.
> >>E.g an access token request/response should provide an identifier linked
> to the reason that motivates
> > Maybe you’ll find the work on RAR and identity assurance in OIDF
> interesting?
> > RAR could be used for indicating a “legitimate interest”, and IA could
> cater for accountability.
>
> You mean the authorization_details and verified_claims ?
> Interesting! Is was wondering whether there was something more concise,
> but I will investigate if that's viable for a machine-to-machine
> interaction like the one
> I'm working on.
>
> Thanks again,
> R:
>
>

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

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

v2.23.0 | Report a Bug | By Email