Closed mmccool closed 5 years ago
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"],
...
}
Zoltan commented: an explicit example of how schemes and protocols can be combined would be useful...
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.
Will leave open until I generate and we review a PR with the suggested changes.
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.
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.
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
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...
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...
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?
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.
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.
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).
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?