Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id BDD393A079A
 for <txauth@ietfa.amsl.com>; Thu,  2 Jul 2020 10:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
 header.d=gmail.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 X1oPtM3p1vTO for <txauth@ietfa.amsl.com>;
 Thu,  2 Jul 2020 10:44:11 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com
 [IPv6:2a00:1450:4864:20::233])
 (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 30D5C3A0798
 for <txauth@ietf.org>; Thu,  2 Jul 2020 10:44:11 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id s1so33323905ljo.0
 for <txauth@ietf.org>; Thu, 02 Jul 2020 10:44:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=CPuV9Jiz3gT21OWoQNOe2Wk8HdRXdybdQWthVR46RgY=;
 b=aGzz9ANQaoyVB8nkCnNRYJRNSJNpLP/swMeTXXzNwnD3LuWJLAt2EP2oK0262Dlxds
 +cInzgZl5r3eR3yDQt75Ao+IUwc+57bx9NN5UMyP7YDYU2asP4u2cCvtLM+O6l5O8IUA
 XJbC2gOOCLXQ5WltGGtjpBLB4bVbH99zbYF4eA7LhWaQCRYoxOceZKQ4E5sLEuF3QVoi
 iDVi3LZWLHQ2fNC9FUqjCKD1JZtSoAZv2Tt7erlWDI2H7cffSdcPYbiq7IN4f3kWQ/DH
 8GLuAY6atLrgH6Oa4qaPnVPCoNyfdNrBeNmBtHPkhkfUc2wCMxPKH7yYGFR2gF9tPn1x
 Kr5Q==
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=CPuV9Jiz3gT21OWoQNOe2Wk8HdRXdybdQWthVR46RgY=;
 b=f2drSC6KuacupLxy/herUuPXuAv7J+TZA1XvR+dffNPHeK3jJFPxPAPspgWvUleYqv
 VffYOUmpUYD4Hq3zI/So9NnQYHs/pXk/ol06OjJ8Fw+3qBIAGgRAN2YNe5vt3vT/1/h0
 2LTYngNyj+Tw9DJxa9uQpkVmfFnVpp6rzdHhTiGiLTCFeuEMrwvNtkpyrBeJ2hdGdQTT
 wSfJI4xcqIodjFPF0vXvUp61Hd6FSMhtraCiwrm5Ulcu6cw/AZKGYD5Qj69WwGJVGImF
 jI4fOYgA3guda1Wj1PWd0+H7aQJ18LMRfCZ+i+o6E7sM+iQIc76k8hTX1YS6bOOSgOPc
 xwSg==
X-Gm-Message-State: AOAM530BzfuClkbE4iDPbKLVb2+Ulu6gI8wn0+ol2yPspzQoctDbsjBN
 3ffbwbZPm0DSqndhxM0DQgHfzCCQJ17rNcRC2iY=
X-Google-Smtp-Source: ABdhPJxd63LznzzZUqpWAiSIrs5sUcVfexsLBTddElez3ZZUNt+zXdBww35v7xYYOn4P4jLvIAifVkFqNHy5tesjNCA=
X-Received: by 2002:a2e:b5d0:: with SMTP id g16mr16202284ljn.246.1593711849163; 
 Thu, 02 Jul 2020 10:44:09 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu>
 <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr>
 <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>
 <dd8ef917-c63a-0070-810a-aecfd9aac0a0@free.fr>
 <CAJmmfSRMWRMQbfZ2ktaRRq1oVeZtXSRf0TGiCJmcLi1FJF6N+w@mail.gmail.com>
 <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu>
 <CAK2Cwb4RMRT-_AJerg6DbGJ08naO1=aHOD3r-RKaU0N5BVvDjw@mail.gmail.com>
 <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr>
In-Reply-To: <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 2 Jul 2020 10:43:32 -0700
Message-ID: <CAD9ie-sSA8EHXA_y4KErvbhWw243EM17C2kEm_T3hCZGqxNqjA@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Tom Jones <thomasclinganjones@gmail.com>, Justin Richer <jricher@mit.edu>, 
 txauth@ietf.org, Tobias Looker <tobias.looker@mattr.global>
Content-Type: multipart/alternative; boundary="000000000000a4d00a05a978f455"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/7SqXFsPt1U7IijOfI6lcWcbNplE>
Subject: Re: [Txauth] Use Case: Directed Tokens
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>,
 <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>,
 <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2020 17:44:13 -0000

--000000000000a4d00a05a978f455
Content-Type: text/plain; charset="UTF-8"

Apologies for the delayed response:

On Fri, Jun 26, 2020 at 9:04 AM Denis <denis.ietf@free.fr> wrote:

> The principle where a RS would only have relationships with one AS would
> make the model non scalable.
> It would prevent to get attributes from two different ASs,  for example:
> identity attributes from a bank and a master degree diploma from a
> university.
>

Where do you see that the RS can have a relationship with only one AS?


>
> For privacy reasons, every AS should know as little as possible about the
> interactions between a client and multiple RSs.
> It is even possible that this goes as little as knowing *nothing at all*.
>

OAuth 2.0 works this way now.


>
> The OAuth 2.0 assumption where the AS is in a position to know all the
> interactions of a given user has with all the RSs
> that an AS server has a relationship with should not be re-iterated.
>

I am still confused why you think the AS knows anything abou the
interactions a given use has with all the RSs. The AS knows which clients
the user is using, but does not need to have any knowledge of which RSs a
client is accessing.


The AS does not need to know anything about the RS. The RS clearly needs to
trust the AS, as it is trusting the access granted by the AS to the client,
but it is unidirectional trust between the RS and the AS.

/Dick

--000000000000a4d00a05a978f455
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Apologies for the delayed response:</div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 26, 20=
20 at 9:04 AM Denis &lt;<a href=3D"mailto:denis.ietf@free.fr">denis.ietf@fr=
ee.fr</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">
 =20
   =20
 =20
  <div>
    <div>The principle where a RS would only
      have relationships with one AS would make the model non scalable.<br>=
</div><div>
      It would prevent to get attributes from two different ASs,=C2=A0 for
      example:=C2=A0 <br>
      identity attributes from a bank and a master degree diploma from a
      university.<br></div></div></blockquote><div><br></div><div>Where do =
you see that the RS can have a relationship with only one AS?</div><div>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
    </div>
    <div><br>
    </div>
    For privacy reasons, every AS should know as little as possible
    about the interactions between a client and multiple RSs.<br>
    <div>It is even possible that this goes as
      little as knowing <i>nothing at all</i>.</div></div></blockquote><div=
><br></div><div>OAuth 2.0 works this way now.=C2=A0</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <div><br>
    </div>
    <div>
      <div>The OAuth 2.0 assumption where the AS
        is in a position to know all the interactions of a given user
        has with all the RSs <br>
        that an AS server has a relationship with should not be
        re-iterated.</div></div></div></blockquote><div><br></div><div>I am=
 still confused why you think the AS knows anything abou the interactions a=
 given use has with all the RSs. The AS knows which clients the user is usi=
ng, but does not need to have any knowledge of which RSs a client is access=
ing.</div><div>=C2=A0</div><div>=C2=A0</div><div>The AS does not need to kn=
ow anything about the RS. The RS clearly needs to trust the AS, as it is tr=
usting the access granted by the AS to the client, but it is unidirectional=
 trust between the RS and the AS.</div><div><br></div><div>/Dick</div></div=
></div>

--000000000000a4d00a05a978f455--

