Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

Brian Campbell <bcampbell@pingidentity.com> Mon, 13 January 2020 18:01 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016A912088C for <ace@ietfa.amsl.com>; Mon, 13 Jan 2020 10:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 lU0A2rIm5gjd for <ace@ietfa.amsl.com>; Mon, 13 Jan 2020 10:01:39 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 AD8F8120877 for <ace@ietf.org>; Mon, 13 Jan 2020 10:01:38 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id m26so11113179ljc.13 for <ace@ietf.org>; Mon, 13 Jan 2020 10:01:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mA5UK0jVOT30/B0E//GIzMGFTLOicC7w8fvBHLl0VUo=; b=PQnsTDBYHaabHEZvFMDm1eFq2nj6iKxhXosuiOwubKSnXly3FjT9J1ERO7E3gHSQ2J 8qhcTv9wwJ+78Czsqa7LXHF5eqGnXxwIWgq4qPjTKB7hKaNksak7fRdzFwrMCer2Bl9W /Go8evpROjbMvkKOw3mvzsa3c5+fhGNWFA1IvFizH7/XBIAwLrZ0f2hoondhffaRtmjX J/3ncMsUf0sFfQ94e5wYjScLTjXvMHMuXJWNfPTI/B6IX6Mo97RhK5xe6Ul+GpxFScyj YRNMMB8eKQM4ay7v4xXAHJbdos1ElyFL4yALjZQSosgNKrbgiKmXm9uvreRFfoVJI+NS IZ0g==
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=mA5UK0jVOT30/B0E//GIzMGFTLOicC7w8fvBHLl0VUo=; b=K0agupRmaa4kzG2YdxEN+bguXcQrNXoMwsDz6imz8Q9bIHwanvhKZENZ4MgHAVkBIG Tg/6r8JDJHVLpQPeLL+qnOI2nlYG6zWJ3V5U5RkTvW0gPhoCrgHIrcwlPrDSXN9LLuXA 5ldien+unpRlYk8PwcwrE/peoB1dJNYyQ8XSeYts+0wLeNp2Vo5BeLesFX4zLo4QFaTA mt3S2dAT3IoopfFCxf7XKfS0KDyotFQRvZB2MgJ7cACuwOo98kCDktjfsnUn64J7BV8x qYa0hBbnPl4EnifqptO55QrP14tNSQWYTiTOhZyM3b1aOAFscECghOXOaqyKHxR5DExy qPyQ==
X-Gm-Message-State: APjAAAV6h6qnnO//jtiEOtjvox9owow2WXCVy+xMInW+KOofsc8EES+0 YiXIwqoYMDniUMVnFk3qmuL7rpjzPtAVc0BDQrasZmxVXySwhLucZcqGtdCpsa0W8UpT7Pj/RMa 9vxlV1gItAGY=
X-Google-Smtp-Source: APXvYqy2La082688Tw09+b6LYeoTYoXNbPZO1yva+lJPNlicq1XW5+nqVjY6tl7NobV1b8jbt4pnuQYGqpa7xb3KMFE=
X-Received: by 2002:a05:651c:2c7:: with SMTP id f7mr11037482ljo.125.1578938496704; Mon, 13 Jan 2020 10:01:36 -0800 (PST)
MIME-Version: 1.0
References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> <CA+k3eCSG3m8=DTnNX-xa2ydaKzHU5WUC5JaWH9vbcMN2XcPnZw@mail.gmail.com> <acc7f28a-fc79-bd44-f228-f8e722415c2b@gmx.de> <CA+k3eCRJkQz2x_kKxQHoD7vtv9BkgsWFfGPJKwXdW3pjJhjBow@mail.gmail.com> <2616175d102b4c19a60c6a79d4256b5e@combitech.se>
In-Reply-To: <2616175d102b4c19a60c6a79d4256b5e@combitech.se>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 13 Jan 2020 11:01:10 -0700
Message-ID: <CA+k3eCT6mZYmY1XQ1_wOi4QY+C_z6or4JUSQN2E+xeYpWgGjgw@mail.gmail.com>
To: Seitz Ludwig <ludwig.seitz@combitech.se>
Cc: Ludwig Seitz <ludwig_seitz@gmx.de>, Roman Danyliw <rdd@cert.org>, "oauth-ext-review@ietf.org" <oauth-ext-review@ietf.org>, Daniel Migault <daniel.migault@ericsson.com>, Jim Schaad <ietf@augustcellars.com>, Benjamin Kaduk <kaduk@mit.edu>, "ace@ietf.org" <ace@ietf.org>, "drafts-lastcall@iana.org" <drafts-lastcall@iana.org>
Content-Type: multipart/alternative; boundary="00000000000037f8ea059c094483"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/7Ss9HN1HBkp3-0mc0ECOb-jPuFE>
Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2020 18:01:42 -0000

Thanks Ludwig,

On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig <ludwig.seitz@combitech.se>
wrote:

> [snip]
>
>
>
> *From:* Ace <ace-bounces@ietf.org> *On Behalf Of *Brian Campbell
>
>
> [snip]
>
>
>
> So in -09 the "cnf" Introspection Response Parameter was the following the
> syntax of the "cnf" claim from PoP Key Semantics for CWTs
> [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax
> of PoP Key Semantics for JWTs [RFC7800] transitively via
> [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP key
> semantics documents are conceptually the same or similar. But I don't know
> that the syntax is the same? Figure 5
> <https://tools.ietf.org/html/draft-ietf-ace-oauth-params-10#section-6> is
> pointed to for mapping between CBOR and JSON but it only has mappings for
> the main top level parameters. Maybe I just don't get it or am missing
> something...
>
>
>
> [LS] No you are not missing something, I just got sloppy trying to do a
> quickfix.
>
>
>
> Background: The reason for defining both JSON and CBOR-based interactions
> is that you might have a powerful client communicating with a constrained
> RS. The client does vanilla OAuth interactions with the AS via the token
> endpoint, but is served a CWT and associated ACE parameters (cnf,
> ace-profile, …) for interaction with the RS.
>
> The pop-key should decode to the same binary representation regardless of
> whether it came in a JSON or CBOR wrapper.
>

Okay, so noting that there is cnf content that doesn't decode to a key, I
suppose I'll just take it on faith that all the relevant or expected usages
involve a key that can be represented in both CBOR and JSON.

>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._