Re: [core] Tossing around URIs to use outside an application

Klaus Hartke <hartke@projectcool.de> Sun, 23 May 2021 10:17 UTC

Return-Path: <hartke@projectcool.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7393A1005 for <core@ietfa.amsl.com>; Sun, 23 May 2021 03:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 xqsseGEQMBt8 for <core@ietfa.amsl.com>; Sun, 23 May 2021 03:17:48 -0700 (PDT)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC803A1004 for <core@ietf.org>; Sun, 23 May 2021 03:17:47 -0700 (PDT)
Received: from mail-pf1-f177.google.com ([209.85.210.177]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1lklB1-0003Td-JG; Sun, 23 May 2021 12:17:43 +0200
Received: by mail-pf1-f177.google.com with SMTP id c17so18436216pfn.6 for <core@ietf.org>; Sun, 23 May 2021 03:17:43 -0700 (PDT)
X-Gm-Message-State: AOAM532sSnjxx7ZkwfMdv+aaJ/VIeqUi0NJCGjEwn65uRseIi1I7om8Y ZqBwx7oJ3hTo96DWuk/5iiVzY3g2imHJdkdIbvA=
X-Google-Smtp-Source: ABdhPJzB6fRnpjxWcVMRJBiqK6saSrwKKfSqggWRpu/vCn57JknHP5pwLh8uwOycHwI1Cu7tR42FfkynxQJhJnlGVb0=
X-Received: by 2002:a63:ed41:: with SMTP id m1mr8047458pgk.252.1621765062236; Sun, 23 May 2021 03:17:42 -0700 (PDT)
MIME-Version: 1.0
References: <YKJltpQ9l6k4tseH@hephaistos.amsuess.com> <CAAzbHvbtysXRCe+E61BcjSFooVBqXcOYdTuAGr4ha=kYtfPuxg@mail.gmail.com> <2D41F5BE-A83A-4C73-95D0-E2CD2B57FA5B@tzi.org>
In-Reply-To: <2D41F5BE-A83A-4C73-95D0-E2CD2B57FA5B@tzi.org>
From: Klaus Hartke <hartke@projectcool.de>
Date: Sun, 23 May 2021 12:17:07 +0200
X-Gmail-Original-Message-ID: <CAAzbHvZaWUdx98TO1YHSUsQuUh=09kFNMqBEeiBR9Ub2wJuZ6Q@mail.gmail.com>
Message-ID: <CAAzbHvZaWUdx98TO1YHSUsQuUh=09kFNMqBEeiBR9Ub2wJuZ6Q@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: =?UTF-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>, "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1621765068; 1c379091;
X-HE-SMSGID: 1lklB1-0003Td-JG
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/U3w1natwjXGrstQDPYEbQLnjQ2U>
Subject: Re: [core] Tossing around URIs to use outside an application
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 May 2021 10:17:50 -0000

Carsten Bormann wrote:
> I think we are reinventing link relationships, just better.
>
> You can’t really “toss” a URI, you are tossing a document (that contains the URI).
> If that document does not specify a link relationship (a purpose), you need application state going along with that or you don’t know what to do with the URI.
> If that document does contain a link relationship (and possibly further parameters), these become part of the application state, hopefully together with the provenance of that tossed document.

That's an interesting thought. I guess, a fully self-contained
document could then look a bit like this:

    Please register your resources with the resource
    directory at <coap://example.org/rd>
    * But I don't fully trust it, so better only
      register your public resources
      (will of the device owner)
    * Also, the resource directory allows you to
      register only resources related to
      YetAnotherEcosystem
      (will of the RD owner)
    * To access the URI, you'll need to have an
      OSCORE security association with example.org
        * example.org has the RPK certificate h'...'
          (certificate pinning)
        * Please set up the security association
          using EDHOC at <coap://example.org/edhoc>
        * But I don't want you to use any ciphersuite
          based on SHA-1
    * To access the URI, you'll also need an
      authorization (bearer) token
        * Specifically, you need a token with the
          scope "Register YetAnotherEcosystem
          resources in a resource directory"
        * You can obtain the token using ACE
          from the authorization server at
          <coap://as.example/>
            * Please connect to as.example using DTLS
            * Use these X.509 root certificates for
              that: ...
    * When you access the URI, you'll need to
      understand the CoRAL vocabularies
      'coreapps.org:resource-directory' and
      'coreapps.org:problem-details'

This could even be part of a CoRAL document. For example, if server A
serves a CoRAL document with a link to a resource on server B, then
server A could tell the client what it thinks is server B's RPK. That
would give the client immediately feedback if it's actually talking to
the server that server A intended (rather than, for example, a server
B that has changed ownership in the meantime). Of course, then the
question is, how server B could update all the links on other servers
pointing to it if it legitimately wants to change its keys,
authorization policies, or CoRAL vocabularies...

Klaus