[Txauth] XAuth "flaws" (Was: Polymorphism (Was: JSON Schema?))

Dick Hardt <dick.hardt@gmail.com> Fri, 10 July 2020 17:59 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 8CB8F3A07D6 for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 10:59:22 -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 eRPgRGSbnB91 for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 10:59:20 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 2CF843A07D4 for <txauth@ietf.org>; Fri, 10 Jul 2020 10:59:20 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id e4so7448152ljn.4 for <txauth@ietf.org>; Fri, 10 Jul 2020 10:59:20 -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=A3xRoOSoBSQSl3zXxyYOimU1a05M9mP7UCIohSSU+rA=; b=AGUwE+cv7c0HSgdgyEsPME5SFvwBULwahE+RKHoMYSo0b77EV8Tbp/IJCjFXZHpo4s 6KAGGWPTIywlQfMH6xxWfBOyjwcn53tWcUGuofCAWP/DF8kFVYtXXQEz5vWN4Hv0VGj7 6yE+DcRWdjYJiMKVkfnSObBAUvjCAkyMh5yHhpLMw09mqPkjqG4bNSeCuuL0YAFoe61p ihjGJhEBrlaebEgRJp5vSdcOWBQkEyuo3hyYRFvm6I9TmBRT1CkbxunRl/KhjNX2g7CD ROwmcGaaEjO9V8UuPFChZPpC3NF6/aEL2fQ4QsdxyTHRShkfWFFp+2OzXw9VBjgdbO/D 79fQ==
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=A3xRoOSoBSQSl3zXxyYOimU1a05M9mP7UCIohSSU+rA=; b=AO+TO2fph/Ww2f+7yJnGU7+rY5cDLz0i9RhyGb4Ldj9ucJzDn+iESmY7nqGKqxH0L8 iJU6W4ZWovQjYvWfaPm/b2qJcejNwWjWf/zcf8N54R/n8IB1AFfar+rZAj2QD/Ep6qL/ L0EPeyOKmMzY9KXWrveOwNzkmsGvNkG+JLIXuj15LKd3hQva2WZTLr6zJMchhzLBsjZD duyJuPeCCkT1oNSXUIUaDiNpmAOkYmOt5ZoEirBJDCakbGk+vKOhc3jWHc5bnYiDjKmT oxrWjecJKLZuMuP1mdlmNP10ohKpOVaGXFNoqDTqMYUkWBLKMRlIK4OuT8IVnSEgpbLz XvLA==
X-Gm-Message-State: AOAM530UBLNdJMnOd3grCf+RMaLDkzvbWgp4l1xKGLGs4O8z+BTSEqKX 2G8ij1HZLZZPLA7ldOCEGHgzhRNoiv+1fN3zBtDu+CPy
X-Google-Smtp-Source: ABdhPJzNKSqnnvdJYGl5qbxr5JJDH0d0t/lS4JEDqndtNi8e5IzfmFazY7cPtpxRSgKoijb+rfd91CNdLgUKuSb2SjM=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr29547445ljh.110.1594403958129; Fri, 10 Jul 2020 10:59:18 -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> <CAD9ie-vFwjQWQZjeL1Qza9MQ5=35qbWW15umyqGhhawFWephLA@mail.gmail.com> <D3EB60DC-6040-480D-A477-C1346130DF96@mit.edu> <CAD9ie-v9MdskdG74Ou__nn9mMmN2gJT6F45mg3dPs7CzJeD7WQ@mail.gmail.com> <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu> <CAD9ie-uJHm4UHzNqreVta6Rrm5iQ=8chAbZqfaUFX6OOyXTbow@mail.gmail.com> <D1CD3AF7-051B-4BBD-9E16-5640FB2A718F@mit.edu>
In-Reply-To: <D1CD3AF7-051B-4BBD-9E16-5640FB2A718F@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 10 Jul 2020 10:58:42 -0700
Message-ID: <CAD9ie-uJSfKXPdeK1DqW5mB+reAdC2Bx1MjiHCLzV+J_YQRubw@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008d8afb05aa1a19ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/oxBL6ffQCF9tUbgmsXY8n2pU52M>
Subject: [Txauth] XAuth "flaws" (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 17:59:23 -0000

Thanks for listing what you consider flaws in XAuth. It simplifies having a
disussion on them, and I hope to get a better idea of your concerns
On Thu, Jul 9, 2020 at 5:46 PM Justin Richer <jricher@mit.edu> wrote:

>
> Haven’t we been talking about them all along in all of these threads?
> Isn’t that what this conversation is largely about? I think I’ve been
> pretty clear, but my concerns include, but are not limited to, the
> following:
>
>  - Use of a ’type’ field to indicate sub-schemas to be parsed and
> understood
>

What is your concern with this? What use case does it prevent you from
doing?


>  - Separation of string-style “scope” parameters from object-style “rich’
> parameters
>

Do you mean that they are not in the same array? Both of these parameters
are in the "oauth_rich" type, but are in their own
"array"


>  - Lack of ability to cleanly define combinations of different approaches
>

This is too vague. Would you provide more clarity?


>  - Outsourcing of query schema to external specs, specifically reliance on
> OAuth 2 technologies that come with OAuth 2 limitations
>

Outsourcing schemas is in the charter. OAuth 2 is just one of those
schemas. If other domains have their own schema, they can use it in GNAP as
well.


>  - Overly verbose and awkward syntax to specify simple requests
>

There is a balance between clarity and brevity. What use case does this
prevent you from solving? This sounds like a stylistic concerns rather than
a "flaw".


>  - Larger possibility of error conditions based on syntax alone (for
> example per the recent update,
>

"larger possibility"? Have you done an analysis of the error conditions in
both?


> if someone asks for a multi-token response named “type”, that’s a class of
> error;
>

Agreed. And it is a compromise doing that, but looked like the best of the
options.

It is a visible error that the client will get immediately in response to
the request. I think an error message specifically about this error would
be really useful.


> if someone puts a “claims” field in an “oauth_scope” typed request, that’s
> an error, etc)
>

Are you saying putting an ignored property in an object? I don't know what
you mean with this one.

/Dick
ᐧ