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

Klaus Hartke <> Sun, 23 May 2021 10:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE7393A1005 for <>; Sun, 23 May 2021 03:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xqsseGEQMBt8 for <>; Sun, 23 May 2021 03:17:48 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 3EC803A1004 for <>; Sun, 23 May 2021 03:17:47 -0700 (PDT)
Received: from ([]); authenticated by 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 with SMTP id c17so18436216pfn.6 for <>; 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: <> <> <>
In-Reply-To: <>
From: Klaus Hartke <>
Date: Sun, 23 May 2021 12:17:07 +0200
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Carsten Bormann <>
Cc: Christian Amsüss <>, " WG" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key:;; 1621765068; 1c379091;
X-HE-SMSGID: 1lklB1-0003Td-JG
Archived-At: <>
Subject: Re: [core] Tossing around URIs to use outside an application
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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://>
    * 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
      (will of the RD owner)
    * To access the URI, you'll need to have an
      OSCORE security association with
        * has the RPK certificate h'...'
          (certificate pinning)
        * Please set up the security association
          using EDHOC at <coap://>
        * 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
            * 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
      '' and

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...