Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08)

Dick Hardt <dick.hardt@gmail.com> Tue, 16 June 2020 16:38 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 2DE063A07D7 for <txauth@ietfa.amsl.com>; Tue, 16 Jun 2020 09:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, T_FILL_THIS_FORM_SHORT=0.01, 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 DxvFGzTPoMEu for <txauth@ietfa.amsl.com>; Tue, 16 Jun 2020 09:38:53 -0700 (PDT)
Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 3E27C3A00C1 for <txauth@ietf.org>; Tue, 16 Jun 2020 09:38:50 -0700 (PDT)
Received: by mail-lf1-x143.google.com with SMTP id m26so1086131lfo.13 for <txauth@ietf.org>; Tue, 16 Jun 2020 09:38:50 -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=HIDH6o3H7zeMfUgLIrqZPma0A3gotIr2w3keZGbikNo=; b=QZkZTszcWdScLZMzTvgvyHa+MSfLdFdsuBlssP0VO9zmkYFe3/ecBQT7PXxMbY+jIC Mdcg12INSki+liiyF5kBed0xrsDWU44/mmKTraMWmZV6upC+xWBXc+GEpqdubSkG3VNL pyZvNfayFNyJGIgCAzmwu5ga66WQlwDa+4WvgNbjFZwwjpTAl/Kya7B8l/z7k/0pjCNi iQ/fcda/wMYvjSVFWwZg8k/5+RR+fwhVA0o7NLkl5J8BbJhDOslMYY2EU3RAjnr7SUBJ sudMW/RhjrFLxelZqkh3uxAzEVgbJqwIT5SaboNVeLXWqzb+JZeIbwp7vSJxQGDVlDdi +U6w==
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=HIDH6o3H7zeMfUgLIrqZPma0A3gotIr2w3keZGbikNo=; b=URsikgxCNvq43HPLFQORdW6tPbDMCzoWtka6JuKbeBwkooDSaLJcVDNtYLLqBaDs1L 3EW7awWgNG20iupDaGH6a5bIJbpJ2x09Uyal3tzrFisIzX123K5Ffekl9tMHGdxjXbJI Y1vEW3IZrQRBq4XtyXHbX3QvS/g+77mrHnhsYXGH+cn/fPRYJCD+qMFaf0tG7R+YhhWe wul9kvP+AYbGJxT2JMuCBdYyA7NgDgGiYllZbBZAfTLS8c03QuWaeotOBdQ73iMWGfck XhckipNZdxICVq6enC8R8Du+xyauSgg3aSLdHUqhd4NMm+DZQREPPoXbLft8yggbThkg 9m3w==
X-Gm-Message-State: AOAM530eBPfhKlmBQH3nDB5LGlePsgpjlJi25r6pI9JJ03RQBHH6Fe7O R3tvncj0hc7DlkqznB2ZM4D0L5Qus9r4grAQ0LM=
X-Google-Smtp-Source: ABdhPJyTFSdICj4d1JDM4d7qmi8YfpysnOR8cTPoOHWp9uyjfDsm2ldV+Fccbr7n7aDKWp8Q7RdzGh1jb/rlXBJbzjY=
X-Received: by 2002:a05:6512:10d3:: with SMTP id k19mr2165611lfg.78.1592325528236; Tue, 16 Jun 2020 09:38:48 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR00MB0688FBD38C5B358245B562F7F59D0@MN2PR00MB0688.namprd00.prod.outlook.com>
In-Reply-To: <MN2PR00MB0688FBD38C5B358245B562F7F59D0@MN2PR00MB0688.namprd00.prod.outlook.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 16 Jun 2020 09:38:22 -0700
Message-ID: <CAD9ie-uXP2po4_h2fQHq9UBEMta8T7TaoP-2bKd_2z=aKbBdXA@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Justin Richer <jricher@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007a376305a8362d15"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/BIJZRDQlAZpZO4YMJ9xZ-ldqLrg>
Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08)
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: Tue, 16 Jun 2020 16:39:02 -0000

It was pointed out to me that the OAuth query parameters are registered,
and therefore an extension point.

I was sloppy in my language, so let me clarify:

The query parameters are a general purpose extension point for adding new
features that don't belong somewhere else, but it was not called out as an
extension point in the Extensibility section of 6749
https://tools.ietf.org/html/rfc6749#section-8

An extension defining a new grant type would use the defined extension
point for grants rather than the general purpose extension point of adding
a new query parameter. The specification defines this extension point
https://tools.ietf.org/html/rfc6749#section-8.3

Similarly in GNAP, I think we should support multiple schemas, and we
should define how new schemas are added. My proposal is that the claims
object members are schema objects, and the contents of the schema objects
are defined by the schema.





ᐧ

On Mon, Jun 15, 2020 at 6:25 PM Mike Jones <Michael.Jones@microsoft.com>
wrote:

> I completely agree with Dick that, as written, XYZ is defining a new
> ad-hoc identity schema, which is unnecessary and counter-productive (and
> probably violates our charter).
>
>
>
> I agree that explicitly reusing existing claims schemas, rather than
> inventing new ones, is one of the clear and compelling advantages of XAuth
> over XYZ.  I’d previously suggested that the Claims section of XYZ
> <https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-2.7>
> be revised to not define new “email” and “subject” claims with an unknown
> schema but that hasn’t been done.  Other instances of this problem occur in
> the XYZ Transaction Request
> <https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-2>
> and Transaction Response
> <https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-8>
> sections.
>
>
>
> Getting this right matters.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Dick Hardt <dick.hardt@gmail.com>
> *Sent:* Monday, June 15, 2020 5:39 PM
> *To:* Justin Richer <jricher@mit.edu>
> *Cc:* txauth@ietf.org; Mike Jones <Michael.Jones@microsoft.com>
> *Subject:* Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs
> XAuth-08)
>
>
>
> comments inline ...
>
>
>
> On Wed, Jun 10, 2020 at 8:07 AM Justin Richer <jricher@mit.edu> wrote:
>
>
>
>
>
> On Jun 9, 2020, at 4:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
>
>
> Forking this topic to a new thread
>
>
>
> +Mike as he has expressed concern about creating new identity claims
>
>
>
> On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <jricher@mit.edu> wrote:
>
>
>
>
>
> On Jun 8, 2020, at 5:33 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
>
>
>
>
>
>
> On Mon, Jun 8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
>
>
>
> <snip>
>
> I don't follow how this would work. Perhaps you could provide an example
> in JSON?
>
>
>
> One method is defining a new value inside the XYZ “claims” request object
> that maps to a specific sub-schema:
>
>
>
> claims: {
>
>    “subject”: true,
>
>    “email”: true,
>
>    “oidc”: {
>
>        "userinfo":
>
>         {
>
>          "given_name": {"essential": true},
>
>          "nickname": null,
>
>          "email": {"essential": true},
>
>          "email_verified": {"essential": true},
>
>          "picture": null,
>
>          "http://example.info/claims/groups": null
>
>         },
>
>        "id_token":
>
>         {
>
>          "auth_time": {"essential": true},
>
>          "acr": {"values": ["urn:mace:incommon:iap:silver"] }
>
>         }
>
>       }
>
> }
>
>
>
> That should look pretty familiar. Alternatively, this could be done with a
> separate top-level request object field:
>
>
>
>
>
> claims: {
>
>    “subject”: true,
>
>    “email”: true
>
> },
>
> “oidc_claims_request”: {
>
>        "userinfo":
>
>         {
>
>          "given_name": {"essential": true},
>
>          "nickname": null,
>
>          "email": {"essential": true},
>
>          "email_verified": {"essential": true},
>
>          "picture": null,
>
>          "http://example.info/claims/groups": null
>
>         },
>
>        "id_token":
>
>         {
>
>          "auth_time": {"essential": true},
>
>          "acr": {"values": ["urn:mace:incommon:iap:silver"] }
>
>         }
>
> }
>
>
>
> In both cases the AS is going to need to knit them together into a
> sensible request policy, especially since the OIDC claims query language
> has overlapping implications to one particular resource, the UserInfo
> endpoint. My contention wasn’t with your proposed solution, my contention
> was you claiming that XYZ has a fixed schema and is therefore limited in
> extensibility.
>
>
>
> One of the objectives of this work is to have extension points. My point
> was that XAuth had a clear extension point for adding schemas. How to
> extend XYZ was not clear in your proposal.
>
>
>
>
>
> I am sorry that the extensibility of the protocol was not clear. It is
> stated in each section that additional items can be added, and I have
> stated repeatedly that it’s extensible and demonstrated how, here on this
> list.
>
>
>
> I think the XAuth proposal is better than the two examples you proposed.
> In your first example, the schema is a second class schema, and in your
> second example, claims are spread across to top level options. Both of
> these pollute other schemas.
>
>
>
>
>
> Not surprisingly, I disagree about the cleanliness of XAuth’s proposed
> approach. The proposal here adds external schemas as extensions instead of
> relying on them internally.
>
>
>
> If anything, I think that the OpenID Foundation would be the ones to
> define how to make an OIDC claims request using this protocol, not us,
> since they own and control that query syntax and everything it implies. We
> can provide a means of extension.
>
>
>
> I also think there’s value in defining a set of core interoperable
> identity fields, which themselves could also be extended.
>
>
>
> All of these mechanisms should be controlled by some combination of
> registries and collision-resistant namespaces, which is the approach I’ve
> taken for extensibility throughout XYZ.
>
>
>
>
>
> JSON by its nature is extensible. Adding new members to an object is
> straight forward. XYZ is not unique here. It sounds like your idea of
> extensibility is telling people that they can add new members to JSON. Of
> course they can. That is like saying you can add new query parameters to a
> front channel OAuth 2 request.
>
>
>
>
>
> Yes, exactly. And that’s exactly how OAuth 2 has been extended. I’m glad
> you see that now.
>
>
>
> I think you are missing my point. Adding query parameters to OAuth 2 was
> not a defined extension point. It was inherent in how query parameters
> work. OAuth 2 did define the type of grant as an extension point.
>
>
>
>
>
> My concern was that XYZ does not have a clear way to add new identity
> claim schemas. You have two examples, add a schema as a member of the
> claims object, which is mixing claims with schema extensions, or adding a
> root member, which is then putting claims into more than one place. It is
> not clear where to add a new schema, so we could easily end up with new
> schemas in both places. That sounds confusing.
>
>
>
> In XAuth, the members of the claims object are the schema. Adding a new
> schema is done one, consistent way.
>
>
>
> I provided a couple examples off the cuff of possible ways to extend
> something, as your base claim was that XYZ could not be extended with new
> or external query schemas. Of the two, I think that it makes more sense for
> it to be a separate top-level object. Why? Because the OIDC “claims”
> request syntax not only dictates claims within the OIDC schema, it also
> specifies how the information comes back. The XYZ claims request talks
> about information that comes back in the XYZ claims section of the
> response.
>
>
>
> I would put the OIDC request to acquire claims from a user_info endpoint
> into the authorization request so that there is a consistent way to get
> back an access token, as opposed to a new top level object that could
> return claims and/or an access token.
>
>
>
> Since the OIDC request allows for targeting specifically to the ID token
> and UserInfo Endpoint, I think it is much cleaner to be at the top level as
> its own thing.
>
>
>
> My point is that XYZ does not *define* how to add new schemas. An
> extension can add anything it wants to the JSON, and as you have shown
> there is more than one way to do it, and I think long term when there are
> divergent mechanisms, the code is going to get ugly in detecting what
> claims are being asked for.
>
>
>
>
>
>
>
>
>
> wrt. "defining a set of core interoperable identity fields", the charter
> says we should be NOT develop a new schema:
>
>
>
> The group is chartered to develop mechanisms for conveying identity
> information within the protocol including identifiers (such as email
> addresses, phone numbers, usernames, and subject identifiers) and
> assertions (such as OpenID Connect ID Tokens, SAML Assertions, and
> Verifiable Credentials). The group is not chartered to develop new
> formats for identifiers or assertions, nor is the group chartered to
> develop schemas for user information, profiles, or other identity
> attributes, unless a viable existing format is not available.
>
>
>
> wrt. OIDC claims, the charter explicitly calls out developing mechanisms
> for conveying ... OIDC ID Tokens.
>
>
>
> ᐧ
>
>
>
> Precisely: the charter says we will have a way to convey identifiers and
> assertions. The XYZ “claims” section lists identifiers that can come back,
> in plain text, and assertions, that can also come back along side them.
>
>
>
> These claims are a schema. We will have an IANA entry for what claims are
> allowed inside of the claims object. This is defining a new schema.
>
>
>
> It’s not a full query language and isn’t intended to be, and I think that
> it would actually be dangerous for this to be a full identity schema, but
> it is itself extensible internally if someone wants to do that. Claiming
> that a list of identifiers is “developing a new schema” is an argument
> several bridges too far from reality.
>
>
>
> You are not inventing new identifiers, but you will be defining which
> strings are being used to represent which concepts. FOr example you have
> "email" vs "email_address", or any other string combination that a human
> would likely interpret as an email like object.  Then there is specifying
> what can be in the field.
>
>
>
> I picked a couple examples out of thin air, with the idea that we’d
> bikeshed them eventually and tie them to a registry. We might want to
> re-use a set of identifiers here, and for that I actually like Annabelle
> Backman’s proposal to the SECEVENT group better than most that I’ve seen in
> the space:
>
>
>
> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers
>
>
>
> That is one schema. And it has advantages for the subject identifiers, but
> obviously does not cover the wide array of other identity attributes.
>
>
>
> Why would we not want to reuse existing schemas? And support all of them?
>
>
>
>
>
>
>
> ᐧ
>