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

Dick Hardt <> Fri, 10 July 2020 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CF513A0955 for <>; Fri, 10 Jul 2020 13:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6hQQnx1TmlQ8 for <>; Fri, 10 Jul 2020 13:33:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87E8B3A094F for <>; Fri, 10 Jul 2020 13:33:06 -0700 (PDT)
Received: by with SMTP id j11so7860665ljo.7 for <>; Fri, 10 Jul 2020 13:33:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VvMhB/FWet+7MRH4jTTcq66zEhMqMWaD/pLU39az49E=; b=Wuut2tzWOtfNk22qlAnZ3RjHa/FJ4Wi60aXT7+V1NwAEjdn8bR17qU3f/s1xk2s3Fc 8Pbjfr83smKNpoAL8rQmaEkHkMFwBtdnCtcV7Z1jBo9a+srF5RVIAzeavNVvtKQs1E4m thCGWlQrnQ4o23MkPTb5H2fh2AXKvvCH6mt7uCr5gDFuiB/gtWRyYnVr9b6cTbovZ2iE cWmK6UI3eeaQYCH89XwiXkNVvcsJN9Mc99nNw1VFRbgIS78pYky1iN/dakD697od4YdU d9xou9Cg+3BExlnQp/YBvmSKT11CFh3X2eLKfTaYGbg1NL2N2tXKWezZczPONXyktJnI cCmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VvMhB/FWet+7MRH4jTTcq66zEhMqMWaD/pLU39az49E=; b=iBqekh5GCHuoIvt0B9t2GcSaztq/UfxgAq0FYrYRMvVxwn5LkRNlvCrIlqVQ+YtKcG oXflZHHnEBHzK/L/dlFhbI+XrKQHL2fQvwELNjWEX9F3+YoChLy8th9yYXYNAPChXYqC RDHFUg21RgprUon9vaMtIDF1oeEdDvVx2b6Se4DeD9sfjvp3Q/ZtjgS65XGoC3PmmMnB gxpVcYanEN+ofSWKMiQJFH7jSi6FzJuucmi/8xAYXkW8DI8mmzoiZepF34T2DshZHT/5 SpHl8pK55YxLL/o61qOWS2z1+p9SXIUtGXBpyJg3bA4TyN+ByqpvZt8C3R7yBCTqAQoO /rhw==
X-Gm-Message-State: AOAM533Mt1XsXgYSRWJELE3ulEkKsB/jBoN7adrFzzDN67A3O/BV4D1C AVVBsSy04OecEAH6ba7mqXc3Va+SCHZrRT4s3v4=
X-Google-Smtp-Source: ABdhPJzHQfX9hnZMykgRTheAZ3tEJJPhZ5CwCGYKsD1j5I022MIn0t9jfEni0BUkoXGDuHb0x9mrQfpJO329f/WO2bo=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr43086128ljg.242.1594413184327; Fri, 10 Jul 2020 13:33:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Fri, 10 Jul 2020 13:32:28 -0700
Message-ID: <>
To: Justin Richer <>
Content-Type: multipart/alternative; boundary="0000000000007a23e005aa1c3fbb"
Archived-At: <>
Subject: Re: [Txauth] WG scope wrt. identity (Was: Polymorphism (Was: JSON Schema?))
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jul 2020 20:33:10 -0000

My interpretation is pretty straight forward:

1) GNAP should be able to return ANY claim, not just identifiers.

2) GNAP should not define any claim schema, contrary to what XZY does

The pushback in the group, which I am pretty familiar with having been a
BoF chair at the time, and I personally worked to resolve, was that
"identity" was too broad, and there was concern the scope included defining
new schemas. The revised charter made that clarification. I don't recall
ANY discussion that GNAP should only return identifiers. The charter reads
that identifiers are included in what could be returned.

If you did not agree with non-identifier claims being in XAuth since the
beginning, why did you not say anything? I have not agreed with XYZ
defining a new schema, and have voiced that concern a number of times.

The above reasons are why I was surprised to suddenly learn your position.

On Fri, Jul 10, 2020 at 1:09 PM Justin Richer <> wrote:

> It seems to be pretty clear that you and I are interpreting the charter
> text differently, so I’d like to hear what the chairs think the best
> approach will be when we finally get to defining what’s included in GNAP.
> This should perhaps be a discussion point for the group in the upcoming
> meeting. Until then, I can hopefully expand on what I interpret.
> The charter uses the term “identity information within the protocol
> including existing identifiers ... and assertions” and not “claims”, which
> I think is more precise and that GNAP should use language instead of
> “claims” for this reason. I think the XYZ use of the term “claims” is a
> mistake and it should change because it’s confusing.
> The only time “claims” are mentioned in the charter is in the section
> about not making assumptions about the client and having a protocol
> “allowing for … Approval of AS attestation to identifiers and other
> identity claims”. To me, this does not say that the protocol should have
> room for more advanced identity stuff, not that GNAP should specify how
> it’s requested or returned.
> There are use cases for getting signed assertions back from the AS as
> well, and so the protocol should allow for that. While assertions can often
> contain non-identifier claims, it’s not up to GNAP to define what those
> claims are, how they’re requested, or how they’re returned. There are also
> lots of valid use cases for the client requesting a specific set of
> non-identifier claims about the user. The question is, how much of that
> detail should we be solving directly here in GNAP? I think it’s pretty
> clear that the answer is “not much at all”.
> My original XYZ proposal didn’t have any identity information in it, much
> like OAuth 2. After talking with Aaron and a few others, I was convinced
> that we could have a very small delta to let the client know who the user
> is. When writing the charter text, that’s what I originally had in mind by
> the “identity” language throughout. Several people spoke up and said that
> they would like space left to return signed assertions as well, and there
> seemed to be enough support to have that as an option in the charter so it
> was added. What I did not see support for, and in fact saw explicit
> pushback against, was defining ways to return additional user information
> in the GNAP response, at least as defined internally by GNAP. That seems to
> be what you’re arguing for doing here.
> I think there will be room, and need, for a protocol on top of GNAP to
> define identity schemas, assertions, session handling, authentication
> contexts, and identity-based APIs in a standard way. It’s my understanding
> that all of this is outside of GNAP’s core focus, but that GNAP should keep
> this kind of work in mind in its design. So that, for instance, we don’t
> accidentally design a protocol that prevents an AS from tying both identity
> information and
> I realize that Xauth had non-identifier claims since early drafts, and I
> disagree with their inclusion. I think that the group is going to have to
> decide how far down this identity road we really want to go with GNAP, and
> I don’t think that’s an answered question yet.
>  — Justin
> On Jul 10, 2020, at 2:33 PM, Dick Hardt <> wrote:
> 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
> identifier.
> 2) XAuth has had non-identifier claims in the examples since -01 (name,
> photo).
> 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]
> 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 <> wrote:
> <snip>
>> 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.
>> ᐧ