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

[Klaus Hartke <[e-mail]>]

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