[Txauth] WG scope wrt. identity (Was: Polymorphism (Was: JSON Schema?))

Dick Hardt <dick.hardt@gmail.com> Fri, 10 July 2020 18:34 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 7104F3A080F for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 11:34:11 -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 f9d3u_4sl927 for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 11:34:02 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 8B9203A07FB for <txauth@ietf.org>; Fri, 10 Jul 2020 11:34:02 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id z24so7532045ljn.8 for <txauth@ietf.org>; Fri, 10 Jul 2020 11:34:02 -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=dIEdN0ZFntIuOpQWFZo7abo2nUHM6HHMkcByKqrp1lY=; b=vadVpyDYv0J4dr8D/xOfqoNiZcHZB/qtmeL0zkJljumJ2VckrqvbMH9N8gIjAqqrDx onnqOkBBU1eKM0ymgVWNh1WKtwiV76qStotc1jtkVBaDDJ/ZOfwSqBeMHATxXYEW3l72 uY1IYIzLDJPotg79a8XT5FHxwBfaptGgTxHdsMHklNPNxBNyDleMLPamTeZLfkH6q6w5 bK6MMsP4vJbJ3FrZuDGb/F+rxqlLJioL/uvL3gOmRfZRw/xz1f9aMqPHhv/BqEqSXWp9 i/hE+l7GKWmWR+7acwm2lOflrc0dkjZm0+fgDjw+I5aRFFiDxTKYN4jmIx1JCB1vUx0J oGlQ==
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=dIEdN0ZFntIuOpQWFZo7abo2nUHM6HHMkcByKqrp1lY=; b=tWw7+7yOmhIifaOWFZK+SK9C7QJPt1gPhv8FfUaPelPwSAWZ+qIQeCv7yInKCa6zxl xGwem7WV7uqO60B2qG5TvcJWWB+JYWvRV+aHPo89Qkvv3Wx1X4l5dizfMWf2LQvDYEnT JbogIJwRy3CT9TlcDi4+PfaDJAZHMcMKrYQ1+w9XHtvivQqTx00/rUACkqh+YuB0hUR3 27einrrI5QBinFF6w5xwbTEaw61ojMofV1vtPd4YlLuQemOBRF1MgdVuW9m0dZfA2q6R xGlvGakrsq6gE5/6xR1NM85dSalxxe4HHjBRAWZoNu/F8fs4pIdHEQVAhOJJi51PeRCx rD0Q==
X-Gm-Message-State: AOAM533IblDDFV79lGe3eMDeJ8/mhAiJ5vS3WLLGESiNF0n5rMBJ0Hhe m08nNGzYVHAFw4gqY92liNT3aXtFl0Q5Kst5Y7GQk4LE5Gk=
X-Google-Smtp-Source: ABdhPJziTiTBwUusHNC7273wIwCojzJYoZ1ND6H1h9gXn5PKxI0odwPKy1Lkq6wYG+YXAhsiPhjXw5GkriUsgWus0wk=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr3574659ljg.69.1594406040321; Fri, 10 Jul 2020 11:34:00 -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:33:24 -0700
Message-ID: <CAD9ie-u0Z_q7Jn-7E==qbv=KwSic=NPctMqYE2njyPieZBTcQg@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a946e005aa1a95d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/4AH7HIn1ac_0uellZG1eQMfvoB4>
Subject: [Txauth] WG scope wrt. identity (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:34:12 -0000

Justin, your stance is surprising for the following reasons:

1) Both XYZ and XAuth use the term claims, rather than identifiers. "A
claim is a statement that one subject, such as a person or organization,
makes about itself or another subject."[1]. A claim is clearly more than an

2) XAuth has had non-identifier claims in the examples since -01 (name,

3) The charter does not state that ONLY identifiers will be returned,
identifiers are one of the examples, as are OIDC ID Tokens, SAML
assertions, and Verifiable Credentials. All of these often bind
non-identifiers to one or more identifiers.

[1] https://en.wikipedia.org/wiki/Claims-based_identity#Identity_and_claims

Justin's stance earlier in the discussion:

My stance is that we allow the client to ask for a small set of identifiers
about the user, or even just ask to “identify the user”, and leave
everything else to a higher level identity protocol. I do not think that
having an identity and profile query/response language at the core of GNAP
is a good idea, and it’s certainly not in our charter.

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

> I’m sorry that you are surprised by my stance, but it hasn’t changed since
> I helped write the section of the charter that you quoted below. A big
> reason that I chose that wording was to support this use case but not to go
> in depth with an identity protocol, which I never really wanted us to do.
> However, it seems as soon as “identity” was brought up previously, people
> immediately jumped into talking about a full stack of user attributes and
> profile information. That wasn’t my intent in talking about identity, and I
> don’t think it’s something GNAP ought to do, at least not on its own.
> I do think there’s room for us to provide identifiers alongside the access
> token, so that’s there. There was stated interest in providing signed
> assertions as well, so I made sure that was enumerated for those who want
> to do such work. And I think it makes sense for us to provide a way to
> describe what kinds of things I want to get from an access token by
> defining a general purpose syntax for describing those things (notably, as
> a combination of reference strings and multi-dimensional objects). With
> these two, we can get most of what we need for a basic login system.
> Anything beyond that is going to need user profiles, authentication
> contexts, session control, and a lot of other identity-protocol stuff that
> GNAP shouldn’t be focusing on. We should keep it in mind as we build GNAP,
> but I think that like OIDC all that important extra stuff should be built
> separately. To me, that’s what not defining schemas and formats means.
> I don’t see any conflict with the charter here, and I’m surprised that you
> do.
> ᐧ