Metadata: Proxy

[mmccool]

A proxy requires a separate URL to access it. A standard tag should be used for this when it is needed. The example from Matthias uses "href". However, should this be embedded in another access scheme, or have its own scheme? For HTTP proxies, do we need to specify anything different from "http"? What about non-HTTP proxies, eg. specifically for WoT systems?

[mmccool]

Here is Matthias' example:

     "security": {
      "authorization": "Proxy",
      "proxyAuthorization": "Basic",
      "href": "http://plugfest.thingweb.io:8087"
    },

I think we can express this using something like:

"security": [
     {
         "@id": "proxy-config",
         "scheme": "basic",
         "proxy": "http://plugfest.thingweb.io:8087"
     },
     {
         "@id": "endpoint-config-1",
         .... // endpoint security config
     }
   ]

In other words, if a value (a URL) is given for a proxy, then the configuration is for the proxy. The other configurations would then be used for the endpoints.

"form": {
    ...
   "security": ["proxy-config","endpoint-config-1"],
   ...
}

[mmccool]

Zoltan commented: an explicit example of how schemes and protocols can be combined would be useful...

[mmccool]

Not sure what schemes and combinations we should look at in the short term. At least basic, oauth, and ocf. What I don't know is whether certain combinations make sense, eg OAuth with CoAP. I'll make a table and may simply mark certain combinations as "unsupported" for now. Basically: (basic, oauth, ocf) x (http, coap). For now, just support (basic,http), (oauth,http), and (ocf,coap) for initial testing. Later on we can add more.

[mmccool]

Will leave open until I generate and we review a PR with the suggested changes.

[mmccool]

See PR https://github.com/w3c/wot-security/pull/86

[mkovatsc]

From "scheme": "basic" the implementation cannot recognize that a forward proxy is needed. The information is implicitly in the proxy field and it is unclear if basic now applies to the device or the proxy.

A proxy probably needs to be combined with any other "scheme". So a proxy field is good, but we should also have a dedicated proxyScheme and probably a proxyId to match additional proxy credentials.

[mmccool]

The way I have set this up if proxyURL is given the entire configuration is for a proxy. If it is not given, it is for the endpoint. The then need to list multiple configurations for all “forms” that use proxies. This approach lets you use whatever security configuration you want for the proxy and use a completely independent configuration for the endpoint.

I should probably try to clarify the example.

[mmccool]

I should comment that in the current proposal you can have multiple configurations using the "basic" scheme, eg. one for an endpoint, one for the proxy. This is another reason not to use scheme names as "tags" eg : in a map, because then you could only use each scheme once. The proposal (using { "scheme": , ... } allows each scheme to be used multiple times.

I do need to improve the writeup now that we've seen some feedback. I have to generate an HTML-based PR for the TD spec anyway...

[mkovatsc]

Within security you use @id to give an identifier that is used within the form (where we should use something like useSecurity). This @id would be the key in an object notation (based on JSON-LD 1.1 way of doing things. The updated example would be like:

"security": {
     "proxy-config": {
         "scheme": "Basic",
         "proxy": "http://plugfest.thingweb.io:8087"
     },
     "endpoint-config-1": {
         "scheme": "Basic",
         .... // endpoint security config
     }
}

Within Interactions:

    "form": {
        ...
        "useSecurity": ["proxy-config","endpoint-config-1"],
        ...
     }

P.S.: I am still not sure if we should use all lower-case value terms or camel-case for scheme values, as the value usually corresponds to an RDF class -- but which can be masked through a JSON-LD term, which is usually lower case...

[mkovatsc]

My issue with proxy suddenly being the important field to understand the scheme is still not solved.

scheme acts basically like the type field for DataSchema: its value decides what sub-class applies, and hence what other fields must/can be present.

Thus, Proxy should be a scheme on its own that then has something like proxyScheme. Maybe useSecurity within the security definition might work, but feels complex. We probably also need a field that says if it is an HTTP proxy, a SOCKS proxy, ..., an HTTP CONNECT proxy -- but maybe this should rather be in a Tunnel scheme?

[mmccool]

I think this is resolved but we should wait until after the Bundang plugfest and implementation feedback from Matthias. One issue is dealing with both protocol-aware proxies (eg HTTP Proxy) and transparent (application-level) proxies. These may require different strategies.

[mmccool]

Going to close this, consider it done, but can raise new issues after testing. I propose to add an explicit checkpoint to the plugfest planning document to test that we have the right metadata here, then close this issue.

[mmccool]

OK, will really close this now. I think Matthias' point about the appearance of the "proxy" field should really change the "type" of the scheme is kind of relevant, but I think the rule is clear enough (if "proxy" appears, the scheme is for the proxy).