[Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))

Dick Hardt <dick.hardt@gmail.com> Fri, 10 July 2020 18:16 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 89DD33A07F3 for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 11:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MNLcTWd1cjMr for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 11:16:24 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 483B83A07F2 for <txauth@ietf.org>; Fri, 10 Jul 2020 11:16:24 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id q7so7534659ljm.1 for <txauth@ietf.org>; Fri, 10 Jul 2020 11:16:24 -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=H1j+gRtGguZiwvV1kaXT609M/iNPeQ7zP8rhKcBUA90=; b=HH1npHUDYMI2kye+MOIFv9OLs5ocVnDvBOkazJ72Awd7kJ4I+/7W21BgDDeo+5PHqe 8HR6gga1948BQauwtzfZgpyQoAQ1fvF4LVDFZxfhhxMsLGd2c4eAX3VgmUyZh+BvhHsQ 2wbXGiVc9Duv9YJeOjSu8rZ+qz+7+pY7GfjKj4NkZz9TxmTbn4vVZSOrAvJ5UqpW8XmK obkbAqY+D5OAAyg6AID1ehJBqY+jrvBuTTpZaQK3rcHWdGNNRRQsnn96mvaXXn54uigF KUG6DzAlghExlIShObx+nGUnI8YoqglH4t+zCpEAd7Yx6iSx/L2yxgTp310Z1Puntz9A hfMQ==
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=H1j+gRtGguZiwvV1kaXT609M/iNPeQ7zP8rhKcBUA90=; b=qettp1bNIi5zZJJLG33uuXShsVKnc5IivNKyyPv6Rt9Br7RIiPR2bzU6ZDu22OrRB5 XcqYN+VJzakbimDUOafQasEcFdmQV8v7C2L3t2V14wwucJEyW0rCSUWIF1lPgSzieD3S WzytPCQm9/zOAmcinAtB0m8g4adMe+Md4M7nLhXBOWIoZUHbHW7hty7NBcto71vN5eyH 7pV363UjH6JpuzUGIsHCWLq63BMipzPm2mJV8JDMAIugGiAV5R4HTssHP6V+YLuNLktC 42ikIrCZT8CvvjNdlTtYuiLcqKvzJld3y8XZU2gmc66TorRV5h+P+h1pjQSZhOqbqjGi PxfQ==
X-Gm-Message-State: AOAM530U54p1iHAUqvaa5/89nPgOPseXzrA/gHvUKpbBY4enbbT8rZS3 Q/kJ+yFcMmWAVsSFIaE279zQolYKdlYPbyMIu34=
X-Google-Smtp-Source: ABdhPJy/Hx6nv1rqpxYrrgkSFKZ57u0sOzlPV0Z4SVyRME9OgMtQ45K/wnAmcaNpglou85yPwbqZdqTx2fuO5J9YPYA=
X-Received: by 2002:a05:651c:547:: with SMTP id q7mr38514519ljp.437.1594404982126; Fri, 10 Jul 2020 11:16:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-vnA98pobbboS00SAHneEG52_8eMxh_sE3r3jg6gyooGg@mail.gmail.com> <E9EC90C9-7A9A-4909-8627-A161B33E941F@mit.edu> <CAD9ie-vyB8+5jS=K_qUHfvxsF2wPV5APRo+7WUDfJxNzJONJpg@mail.gmail.com> <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu> <CAD9ie-u9z7Mc-wNjztoOTy4N_Z9jFDc2Sb6quLspasMGAMKdSw@mail.gmail.com> <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu> <CAD9ie-tpuisauOFGiUj65-RcYPtcvW_gZP1CAadqq5cE6P36HQ@mail.gmail.com> <EE4A7D91-1106-44CB-92BF-C3AA3649BDFE@mit.edu> <CAD9ie-saoc2FUm46r4h1B27iYK04j_skf5-zJR7EXLmWBzj=hA@mail.gmail.com> <F41A8F88-C1B4-4CE2-8573-7A03C086D25B@mit.edu> <CAD9ie-tHCg9Ti1xWuzUP5EGLAcU2cpFALErqq98+fPnD3enZCQ@mail.gmail.com> <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu> <CAD9ie-uwz_Li7n9iuX_--YtWeE+HX5sWEe95nZ8Y0akYh8WTHg@mail.gmail.com> <A7E1F61B-78F8-4647-847A-E1C8909EA452@mit.edu> <CAD9ie-tSjEWT-+D43yKaFZmEdFcbL=fyM0kHuFX_fNa4zHdm1w@mail.gmail.com> <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu> <CAD9ie-syw5YJVsJHncZ-PcLQbYC4r=4LLSQCKtMP=-hGKqT0SA@mail.gmail.com> <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu> <CAD9ie-vV-pH6oebREkfY5rZ=8vYZpD2irjyjJ=4mvfKKeKY4-A@mail.gmail.com> <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>
In-Reply-To: <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 10 Jul 2020 11:15:46 -0700
Message-ID: <CAD9ie-vy0iKn6HMD-97jd5MeFtshqpzrGtvvwOX_Ze91qusJKQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000967b1d05aa1a5663"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/ifCi-waAW0BRHu5ze7LDwghUxO4>
Subject: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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: Fri, 10 Jul 2020 18:16:27 -0000

inline ...

On Thu, Jul 9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:

> Yes, the core idea is to not have to parse an assertion to get back the
> core authentication information, which consists of an identifier (iss/sub
> pair in OIDC, but could be a number of things). Sometimes the client is
> going to want the rest of the identity information, but If the user’s
> logged into the client before, the client has likely cached that info and
> probably won’t need it, and sending it would be a violation of privacy
> principles.. The client would want the info pretty much just in these cases:
>  1. The client has never seen the user before.
>  2. The user’s information has been updated since the last time the client
> saw it.


> Now for case (1), how would the client know if it wants to request the
> user’s profile info or not, since it doesn’t know who the user is?

But the client could know who the user is. The client may have used a
different AS to authenticate the user. The User may have self identified to
the client. The client may have a cookie saying who the user was and the
user said that was them. While the latter cases are really a strong hint,
they are likely right most of the time and can lead to a user experience
basde on that hint

> And the AS won’t know if client is going to want the profile info, since
> the AS won’t know if the client has the user’s info or not. Sure, the AS
> might have seen that client and that user combo previously, but it doesn’t
> know if the client needs an update.

The client can share with the AS the user it knows or thinks it is dealing
with, which could let the AS respond if the information was new. This could
be the case for an AS that is providing claims, but not authentication, and
could happen silently. The user would only interact if the user information
had changed, and the client wanted the updated information.

> And for (2), the client won’t know if the user’s info has been updated or
> not because it doesn’t know who the user is yet. If the AS can provide some
> time of updated stamp to the client, the client can pull the new info when
> it needs it.

See above.

> If you ignore both of these cases and put all the user information inline
> with the main request/response, you end up in a situation where the client
> always requests everything and the server always provides everything, since
> you can’t be sure you’re not in situation (1) or (2) ahead of time.

See above. There are a number of other states the client could be in.

For example, the client could be stateless about user information, so it
knows it is ALWAYS in state 1.

> This is really what I mean about the two-stage identity protocol.

I know what it is. Per above, GNAP lets us support a wider set of use
cases. Why limit ourselves to what OIDC supported?

> In the first stage, you push the bare minimum of what you need to get the
> user known to the client. In the second stage, the client uses its access
> token to call an API to get whatever else it needs to know about the user.

>From a privacy perspective in non-enterprise use cases, I think the user
should give consent to any updated personal information to a client. In
general, the client should not be able to get the latest information about
a user whenever it wants.