Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Daniel Migault <mglt.ietf@gmail.com> Tue, 29 June 2021 18:11 UTC

Return-Path: <mglt.ietf@gmail.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 EF0743A3C94; Tue, 29 Jun 2021 11:11:43 -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_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 Z_swU0cPz6Hg; Tue, 29 Jun 2021 11:11:39 -0700 (PDT)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 500563A3C93; Tue, 29 Jun 2021 11:11:38 -0700 (PDT)
Received: by mail-qv1-xf30.google.com with SMTP id u8so8229638qvg.0; Tue, 29 Jun 2021 11:11:38 -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=bJZGQXWy7s0HOfZWppubtg7lKOwKhNRMRaOlHzQu7jA=; b=FWh8ydh0EUg8/0n+KH/i0DA9uczp6eEssOJyn3AsNxJTez/PZBKuxkQwhHMiEhCwyB WJTZm9GKNrh9ys/T0hQ7fkdF4TK/e0F5NVO8InJLVQUDH7SAv11T5/RkehYEEddnYaDy WmDq300fDZ/ocYhAmP1c8Eo00df/W2fy96yqRkzZoIs/xoAkPbEeEXo5pr18CzUp0x7E KXQ8quuFQ5uFIFGpK9HRlmCl+lO8lYSrnW8tyMTWP/t6mdN9tHT1O6cOyQkj5s2PSieL Eo3MycS7Gmsm5eovqVNjDH9sql0SGnqMS9aWrC2ZVlVRmp35HtUV6SbnzN5FuAlJPKSs 8zIQ==
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=bJZGQXWy7s0HOfZWppubtg7lKOwKhNRMRaOlHzQu7jA=; b=TVT1EVTdxedz0ktiUcZDXmpsXpMmE8pV2xpKVKDFx3Jum/EquYm3DnAYepEhDKnlH9 UlJVm/zD7L4gD3t3ve0JKmKcV+DhhJx7NQy1DEdNDBSRRts5hsGja+rbPBi8XI+i1cCY DFFIxd6EFfM4ga23TrV4oR9G80QSnemw2/DEyKV+OVwe/fKXg1oOQw+kG5nsaZ7UOVZM kiymsp0cEsAgxUPYF/g1Q4A+iuX5R2HjTNhNn0YBj7AjSakrzsAJ+wdtTLx2CgBnl+hL FJUfsgCERAm4Fc8PPeXvojorwSEKRpyuFPL50zU1kyIcmPFWQ1XeGCZTvKUUpMVQG65U zTiw==
X-Gm-Message-State: AOAM532uqizqrgz6KQcYJenYcLUv+OiflFUGE6anvX8rImi8xUwu042z Jau1si2gGgo3Q+LAyb8dIwJQUYMoXn1USH4B1X0=
X-Google-Smtp-Source: ABdhPJzEAZqbUvLPn8+inp010M3GNBEq9vBtB3z5kpBXnFWsAgeQmYsI8GVNGsDxMma8NsG6d1eC6tCe8ULNipc1sJs=
X-Received: by 2002:a0c:ebce:: with SMTP id k14mr31898760qvq.52.1624990295441; Tue, 29 Jun 2021 11:11:35 -0700 (PDT)
MIME-Version: 1.0
References: <161659738410.3239.3955409176349739508@ietfa.amsl.com> <5634f824f7b14878b5d7d1fdd3b2ed33@combitech.se> <EE1CBB56-8951-473C-A006-875D49BEE350@ericsson.com> <AM0PR0302MB3363E4EB817969E6B34FBBCF9E369@AM0PR0302MB3363.eurprd03.prod.outlook.com> <F44C49D2-C08E-4C04-A751-05ECBBB1DBA9@tzi.org> <AM0PR0302MB3363C4C6DBD796E67986BD079E369@AM0PR0302MB3363.eurprd03.prod.outlook.com> <43222AD5-BA56-423F-98C7-65128A6C35B6@tzi.org>
In-Reply-To: <43222AD5-BA56-423F-98C7-65128A6C35B6@tzi.org>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Tue, 29 Jun 2021 14:11:23 -0400
Message-ID: <CADZyTknQEYbv=3vo_MfjGeWmJOcU-QfkFua-ZGnFHfXhni=omQ@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Ludwig Seitz <ludwig.seitz@combitech.com>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "art-ads@ietf.org" <art-ads@ietf.org>, "draft-ietf-ace-oauth-authz@ietf.org" <draft-ietf-ace-oauth-authz@ietf.org>, The IESG <iesg@ietf.org>, Seitz Ludwig <ludwig.seitz@combitech.se>, "ace@ietf.org" <ace@ietf.org>, Francesca Palombini <francesca.palombini@ericsson.com>
Content-Type: multipart/alternative; boundary="00000000000052c3c305c5eb898a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/_mZiFUvdqaQFybwgWTzVZOwTmes>
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
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: Tue, 29 Jun 2021 18:11:44 -0000

Hi,

So here is the current text:
"""
 CBOR is a binary encoding designed for small code and message size.
Self-contained tokens and protocol message payloads are encoded in CBOR
when CoAP is used.
"""

I think Carsten is suggesting the text does not limit the use of CBOR to
the use of CoAP but eventually when other protocols are used..The
difference is that when CoAp is used there is a stronger insentive to use
CBOR than when CoAP is not used. If that is correct, we could clarify that
by adding. ""When used outside CoAP, the use of CBOR remains
RECOMMENDED.""".

Please provide some text that would address your concern.

Yours,
Daniel


On Wed, Jun 16, 2021 at 9:18 AM Carsten Bormann <cabo@tzi.org> wrote:

> On 2021-06-09, at 12:45, Ludwig Seitz <ludwig.seitz@combitech.com> wrote:
> >
> > Hello Carsten,
> >
> > Can you clarify what exactly you consider is broken and why?
>
> What: attaching the representation choice to the protocol choice
> Why: Because the protocol may transport data that were generated with
> another protocol (or no particular protocol) in mind.
>
> So, recommending as a default choice is fine, but saying that the protocol
> choice dictates the representation choice is too limiting.  Maybe the MQTT
> people discover CBOR at some point :-)
>
> Grüße, Carsten
>
>
> >
> > I was indeed trying to attach the 'when' to both arms (token encoding
> and protocol message payload encoding), but I don't have a strong opinion
> on this. If the WG can decide how this should be I will implement.
> >
> > /Ludwig
> >
> > -----Original Message-----
> > From: Carsten Bormann <cabo@tzi.org>
> > Sent: den 9 juni 2021 09:15
> > To: Ludwig Seitz <ludwig.seitz@combitech.com>
> > Cc: Francesca Palombini <francesca.palombini@ericsson.com>om>; Seitz
> Ludwig <ludwig.seitz@combitech.se>se>; The IESG <iesg@ietf.org>rg>;
> art-ads@ietf.org; ace-chairs@ietf.org; draft-ietf-ace-oauth-authz@ietf.org;
> ace@ietf.org
> > Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on
> draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
> >
> >
> >> In 2021-06-09, at 08:42, Ludwig Seitz <ludwig.seitz@combitech.com>
> wrote:
> >>
> >> " ... size.  Self-contained tokens and protocol message payloads are
> encoded in CBOR when CoAP is used.”
> >
> > This is not what the old NEW text says.
> >
> > (The new NEW text attaches the “when” to both arms.)
> >
> > The whole idea of attaching the representation choice to the protocol
> choice is broken, but if we pursue it, we at least need to make the logic
> clear.
> >
> > (1) If you use CoAP, you use CBOR for protocol message payloads.
> > (2) Self-contained tokens use CBOR.
> > (3) No other hard limitations are implied, but of course CBOR is the
> format of choice to maximize interoperability, so deviations from that need
> to be justified.
> >
> > Grüße, Carsten
> >
> > _______________________________________________
> > Ace mailing list
> > Ace@ietf.org
> > https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>


-- 
Daniel Migault
Ericsson