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

Tom Jones <thomasclinganjones@gmail.com> Fri, 24 July 2020 17:32 UTC

Return-Path: <thomasclinganjones@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 4E2313A1092 for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 10:32:38 -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 9knRwWVOzPeE for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 10:32:36 -0700 (PDT)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 54B133A1089 for <txauth@ietf.org>; Fri, 24 Jul 2020 10:32:36 -0700 (PDT)
Received: by mail-oi1-x230.google.com with SMTP id t4so8637598oij.9 for <txauth@ietf.org>; Fri, 24 Jul 2020 10:32:36 -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=73aMI1/FOoliR+n0uVKBy7MHLv6+rgEjK8tAUIzd0O4=; b=EKrqOU0kPnY5fOUeY8+h5+apSkJEjlfEScIfRfGU8mIsDiMgKv1SUnTimv2ArdApcB 60WwBFiGholJECl0ge3bTPhmU6C7rW2JwGkfnv7aho0FmsHCvMdlQUf4W5pR3CQ6e1jQ 24wfeRh3+QGj2D8kHOw1ZzxXL+Op+2EDRwOyZ7Vknb5VgKeE4Af2OHyvLJLFx3Ji+6yI HGMLM794LFYOx/mXDSfXpGq9b5BsjuC1zx5p+f4unx2rXBGxWYkQIn3MpmQqh6un7YCG qj8OHn4ru5nkGauxcbe90BKLVWVFN6OnuSs7jl70v786Lf/YFM15ACBKClQT53y6cu8o WxlA==
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=73aMI1/FOoliR+n0uVKBy7MHLv6+rgEjK8tAUIzd0O4=; b=dZidJlFiL8gnQXYHkjKS7bO6deTM0iEP1aANL3wg3Nfv1fj6cwTthWDS4Ng7BX9UEK HAsrgWrRhsoK0L5yT7tUVqgQ/hVagTvrSOqyqIifcRxoDuAkIMZdMeFaktZp1W4++x6f f00Dm2oEfin6fJJrZqnORT5lgyPpMbRu5BUzc9Gkyc9VGha8Sokl0pTgN2uUUyAUrbiJ e9ZW7/N6DKZ5Q3P9sh4F1CatDDgWXdNmW7GJDhSV0STozcZA3rwq1h0PpjMWXHO2RMyK EIzw8wuvEpgiCcTghznuScMKyJEreMODXITBPP6YwbQwBv8GTueIpBgvRs7jkzMsSV3V DBZg==
X-Gm-Message-State: AOAM532cq4gA1IELHJ74/JoDSpXpk9msliTmPM8lDc6jhRbqVVPLhKxf lyx71G+bj/8FIoR4IP/yOJp3bmhhGowEbIpCI/0=
X-Google-Smtp-Source: ABdhPJxAxSYL4+6Q9w3+tq9inAk7rR1CsZeS7o0Qg3npZtMtSyvmQE+JO5HB1/PmsHl8QzuwzxkzZW7XR1awYr0xD9I=
X-Received: by 2002:aca:aa57:: with SMTP id t84mr9231254oie.131.1595611955574; Fri, 24 Jul 2020 10:32:35 -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>
In-Reply-To: <CAD9ie-u9NUgPSFyUgeeuOYjJewmbugUON64cTttqhWWFGxf41g@mail.gmail.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Fri, 24 Jul 2020 10:32:24 -0700
Message-ID: <CAK2Cwb4CR7PPDiifvv9s88OyBGpGNWCVSamY8xXp3PJxSx9wVg@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Francis Pouatcha <fpo@adorsys.de>, txauth@ietf.org, Denis <denis.ietf@free.fr>
Content-Type: multipart/alternative; boundary="000000000000cfba7505ab335b3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/IY7cLdI0aHBMdCn5vHDjxyJvwwA>
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 17:32:39 -0000

Nat and I just had this discussion about claims & the claims aggregation
spec.
An example about claims that are not entirely about the user is the gurdian
ship case.
That case can be solved by creating a signed set if claims (which needs a
name) from the RO granting approval to the user to make a "ID Token"
(whatever) from the as to the client to be passed to the RS.
my suggesting is that claim as not necessarily attributes and the data
about the ro from the rs are distinct from the claims about the user from
the as.
I do not believe that claims aggregation is about claims (at least not
often).
so then the data from. the ro would never be a claim, even tho it was
identical in form and substance from the claim produced by the as.
Peace ..tom


On Fri, Jul 24, 2020 at 10:25 AM 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
>>
>