Re: [Txauth] Claims [was: - Dictionary]

Dick Hardt <dick.hardt@gmail.com> Fri, 24 July 2020 19:07 UTC

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 F38013A08FA for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 12:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g--ultf4hxLT for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 12:07:07 -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 04FD63A08F5 for <txauth@ietf.org>; Fri, 24 Jul 2020 12:07:06 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id h22so11035031lji.9 for <txauth@ietf.org>; Fri, 24 Jul 2020 12:07:06 -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=hmns8f0Fg4QMAjVprMKQP8heu8St/yCbqgHQpxGh5Tk=; b=Pu102gZUmzU2B8F9X1cH+c3k729CsPI84bqIGkpZvSaxZdo5be7rYp9OBUF7wm+/AL APj+zmrGnM+S9satjiuBxdNBlw2KX6c07nFaY7hzMbzI7m4CyAwzO/voLz/gNYdi+maJ ZucXWNfoGS3/BjUXMXvEqXrYNAOZnrYj4e9IkKQfrVG8CVZLvawjUVAvh1xd8ap+PYC2 R0H2evRKaDXPbwtnkNjEC1kV/C+7yIVWNfUQNqp4KcFqeZLIVjhycIAh/b+bwN7tlAoN ZP5MUVBpCx7EI2bvE5YGr/54AnzYr3JCDJzCJ/ESqidPpufkmb0GTUtehhpfUk1PFXwO vrAA==
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=hmns8f0Fg4QMAjVprMKQP8heu8St/yCbqgHQpxGh5Tk=; b=GfrXwwt1Gt4wv5eUSwxpKr/fwI7cONHBhWLrayn7wDbEdXmBEauFKmcJ0nbt+HI9v5 JH1aUu4nYxI65Gy6OF45ciGESQWar9rHpoe9ZATIx4bMO/hgTzPq6c1YrisBAdkDBvcm hT5BswEz4XpdbGznA6vkCpuKtYtM2bcErSoFyD3EgvNnVXg3N2ffkSqMbvLYaAJWRPj9 B5tmL4kxEHIuV/cBoFpwdMHpuNjvyx9MELL2aWhHUQTZZlOt7ibyWyY0B3rG9yua7R9/ ZCO0vdpl0yTSTANje79I3+WyTeqazT5T7qR0OD+Dc1QVTZmUiggsxfNtRV4JmWoly0fj e5ow==
X-Gm-Message-State: AOAM533/cDzAY843vnc+6afV7DPNvFkMZsbXLlu+FH/5c1imh4c2Njxe 29WFyuP5SaXDl35Z36AAx5+K86A/u4M16jN2guU=
X-Google-Smtp-Source: ABdhPJzw65Z7S41gRa0xPSxnVyKnvrTQmO4EGNCXmOJ4JJTwK7wYF7O9q7wz4k/nOgCQcfWx0J738y2QOpT82ViHTTM=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr5154816ljg.242.1595617624903; Fri, 24 Jul 2020 12:07:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyO2C1E3Sg58CrSVT81t0T3iCTY87tdAx+a8d2A+cNa3nA@mail.gmail.com> <CAD9ie-vMzepgmaP-jUunKSo-chWrGpB230TWgJq7u8Yt-afDxA@mail.gmail.com> <CAOW4vyObyZC7USUqsW_qdDV9Hcpvg9OHKmM1yMEjSUvmjx0UZQ@mail.gmail.com> <CAD9ie-sWn41XDiwyFMcTgV3a8MMESXqf36fNJcTaSYDKwU+LPg@mail.gmail.com> <CAOW4vyNzGG95eNf6RRLf_jgHoQDMJHz8kPF10EENeaAq9vkrVQ@mail.gmail.com> <CAD9ie-vPDMPM8CRid169WsssD0r3dWNqoNCDJcgrxEs+MfvtjQ@mail.gmail.com> <CAOW4vyOjpL3Qoy02uV1dxc+wYir+yh0wWKiaV93OqzRXtk_Sxg@mail.gmail.com> <CAOW4vyMgW=3-nrgODnhj-BweWhJgW3WzTJDhSAwdnHFdho6msg@mail.gmail.com> <B55BD16B-8982-4621-A35F-6878F5045630@mit.edu> <CAD9ie-vA07gB-sQNc4Ft3jr6586N-Jh7dE5-e9ob8-wN_B0Xiw@mail.gmail.com> <CAOW4vyPQgQZ_fZB_rHvWFCvrTon4Vix7raTGG9gdc=Z1_=YA-w@mail.gmail.com> <EE0A9241-60D6-493F-9351-2F607D59D3E2@mit.edu> <CAD9ie-u9NUgPSFyUgeeuOYjJewmbugUON64cTttqhWWFGxf41g@mail.gmail.com> <E5F32EB4-D47E-4E40-9F2A-9C25E7DFB86B@mit.edu>
In-Reply-To: <E5F32EB4-D47E-4E40-9F2A-9C25E7DFB86B@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 24 Jul 2020 12:06:28 -0700
Message-ID: <CAD9ie-v1aRaGWEsrs71YfzZ2pdzEdLmmzKfzpVCY1dEHStnJmA@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Francis Pouatcha <fpo@adorsys.de>, txauth@ietf.org, Tom Jones <thomasclinganjones@gmail.com>, Denis <denis.ietf@free.fr>
Content-Type: multipart/alternative; boundary="000000000000bad5bb05ab34adfc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/Gf7nNfLp4w_9_CChpe1l__fjJto>
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 19:07:09 -0000

Justin, thanks for clarifying.

What are some examples of other "direct data" that the GS may return? If it
is not in core GNAP, do we need to worry about now? We can then give the
direct data from the GS that is not a claim, an appropriate name in that
document.



On Fri, Jul 24, 2020 at 11:46 AM Justin Richer <jricher@mit.edu> wrote:

> Dick: No, I think you’re misunderstanding what I’m saying. I agree that
> “claims” are about the user, in this context*. But the AS could return
> other data directly to the client that isn’t about the user. Those aren’t
> “claims” by the classical definition. Also since “claims” can come back
> from places other than directly, then we shouldn’t call everything that
> comes back a “claim”.
>
> I’m arguing that we keep “claims” to mean what it already means and come
> up with a new word to mean “things that come back directly from the AS”.
> These aren’t meant to replace Francis’s more complete definitions, but to
> simplify:
>
> Claims:
> - information about the user
> - can come back directly from the AS
> - can come back in a resource from the RS
>
> Resource:
> - Returned from an RS
> - Protected by access token
> - Could contain claims about the user
>
> Direct data (or some better name):
> - Returned directly from AS
> - Could contain claims about the user
>
> I think the problem is that some people are using “claims” to mean #1 and
> some to mean #3. It’s clearly #1 in OIDC. But: It’s important to remember,
> when talking about OIDC, that an IdP in OIDC combines an AS and an RS into
> one entity for identity information. There can be other RS’s as well, and
> there usually are in the wild, but the one defined by OIDC is the UserInfo
> Endpoint. The fact that it returns user data doesn’t make it any less of an
> RS.
>
>  — Justin
>
> * In the wider context of things like the information claims inside a JWT,
> the claims could be about literally anything, but that’s not what we’re
> discussing here and it’s not how it’s being used.
>
>
> On Jul 24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> In OpenID Connect (OIDC), the Client can obtain Claims directly from the
> OP in an ID Token, or the Client can obtain Claims using an access token to
> call the UserInfo endpoint, a Protected Resource[1].
>
> The Claims are about the User (not a RO).
>
> In XAuth, I'm proposing the Client may obtain bare claims from the GS
> directly in addition to the mechanisms in ODIC.
>
> So I don't think we are changing the definition of Claim from how it has
> been used in OIDC, and I fail to see any reason to NOT use Claim.
>
> Justin: you allude to Claims being about a party other than the User.
> Would you provide an example?
>
> /Dick
>
> [1]
>
> UserInfo Endpoint
> Protected Resource that, when presented with an Access Token by the
> Client, returns authorized information about the End-User represented by
> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use
> the https scheme and MAY contain port, path, and query parameter components.
>
>
>
>
> ᐧ
>
> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
>
>> I want to focus on one aspect here:
>>
>>
>>> A Claim is a well understood term in the field. We should use it. It is
>>> still a Claim if it comes directly from the GS or from an RS.
>>>
>> I do not understand why a Resource release by an RS shall be h to as a
>> claim, even if the content of the Resource is an assertion. It will lead to
>> confusion. If we limit claims to information GS releases into Token, User
>> Info, and other objects it returns, this will help separate
>> responsibilities between GS and RS. As soon as RS services and information,
>> this is called a Resource, no matter the nature of the content of that
>> information.
>>
>>
>> This is exactly why I don’t think we should use “claim” in the way that
>> we’re using it. Yes, a “claim” could come back through an RS — but in the
>> context of GNAP, that makes it a resource. So we need a different word for
>> data coming back directly from the AS to the client. Sometimes it’s going
>> to be about the user, and that’s what we’re going to focus on here, but
>> since you can also get information about the user from a resource we can’t
>> just call it a “claim”. I think this has been at the heart of a lot of
>> confusion in recent threads, as well as confusion about the scope of the
>> inclusion of identity in the GNAP protocol.
>>
>> So let’s let “claim” mean what it already does, and let’s find a way to
>> differentiate between when an item, claim or otherwise,  comes as part of a
>> resource and when it comes back directly. This is an important
>> differentiating feature for GNAP.
>>
>> Some straw man ideas, none of which I’m particularly in love with:
>>
>>  - direct data
>>  - properties
>>  - details
>>  - statements
>>
>> The important thing here is that it’s not necessarily :about: the RO, and
>> that it is :not: in a resource.
>>
>> Any other thoughts?
>>
>>  — Justin
>>
>
>