diff --git a/ontology/wotsec.html b/ontology/wotsec.html index 93db6052..1cf87290 100644 --- a/ontology/wotsec.html +++ b/ontology/wotsec.html @@ -48,15 +48,15 @@
IRI: https://www.w3.org/2019/wot/security#SecurityScheme
Metadata describing the configuration of a security mechanism. The value assigned to the name scheme
MUST be defined within a Vocabulary included in the Thing Description, either in the standard Vocabulary defined in § 5. TD Information Model or in a TD Context Extension.
For all security schemes, any keys, passwords, or other sensitive information directly providing access MUST NOT be stored in the TD and should instead be shared and stored out-of-band via other mechanisms. The purpose of a TD is to describe how to access a Thing if and only if a Consumer already has authorization, and is not meant be used to grant that authorization.
Each security scheme object used in a TD defines a set of requirements to be met before access can be granted. We say a security scheme is satisfied when all its requirements are met. In some cases requirements from multiple security schemes will have to be met before access can be granted.
Security schemes generally may require additional authentication parameters, such as a password or key. The location of this information is indicated by the value associated with the name in
, often in combination with the value associated with name
. The in
name can take one of the following values:
header
:name
.query
:name
.body
:name
. When used in the context of a body
security information location, the value of name
MUST be in the form of a JSON pointer [[!RFC6901]] relative to the root of the input DataSchema
for each interaction it is used with. Since this value is not a fragment identifier, and is not relative to the root of the TD but to whichever data schemas the security scheme is bound to, this value should not start with "#
"; it is a "pure" JSON pointer. Since this value is not a fragment identifier, it also does not need to URL-encode special characters. The targeted element may or may not already exist at the specified location in the referenced data schema. If it does not, it will be inserted. This avoids having to duplicate definitions in the data schemas of every interaction. When an element of a data schema indicated by a JSON pointer indicated in a body
locator does not already exist in the indicated schema, it MUST be possible to insert the indicated element at the location indicated by the pointer.. For example, pointing to a key of a Map where that key does not exist in the corresponding Data Schema, the key and its value, which is the credential, would be inserted to the Map at the specified location during the operation execution. On the other hand, pointing to an Array's item with a number as the item index, that number should be outside the range of the Array's already specified items in order to not alter the strict sequence of items. The JSON pointer used in the body
locator MAY use the "-
" character to indicate a non-existent array element when it is necessary to insert an element after the last element of an existing array. The element referenced (or created) by a body
security information location MUST be required and of type "string
". If name
is not given, it is assumed the entire body is to be used as the security parameter. cookie
:name
. uri
:name
. This is more general than the query
mechanism but more complex. The value uri
SHOULD be specified for in
in a security scheme only if query
is not applicable. The URIs provided in interactions where a security scheme using uri
MUST be a URI template including the defined variable.auto
:auto
is set for the in
field of a SecurityScheme
, then the name
field SHOULD NOT be set. In this case, the application of the SecurityScheme
is subject to the respective specification for the given protocol (e.g. [[!RFC8288]] when using the BasicSecurityScheme
with HTTP).combo
security scheme and allOf
. In some cases parameters may not actually be secret but a user may wish to leave them out of the TD to help protect privacy. As an example of this, some security mechanisms require both a client identifier and a secret key. In theory, the client identifier is public however it may be hard to update and pose a tracking risk. In such a case it can be provided as an additional security parameter so it does not appear in the TD.The names of URI variables declared in a SecurityScheme
MUST be distinct from all other URI variables declared in the TD.
IRI: https://www.w3.org/2019/wot/security#allOf
Domain includes | wotsec:ComboSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#oneOf
Domain includes | wotsec:ComboSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#proxy
Domain includes | wotsec:SecurityScheme |
IRI: https://www.w3.org/2019/wot/security#refresh
Domain includes | wotsec:OAuth2SecurityScheme |
IRI: https://www.w3.org/2019/wot/security#token
Domain includes | wotsec:OAuth2SecurityScheme |
IRI: https://www.w3.org/2019/wot/security#alg
Domain includes | wotsec:BearerSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#apikeyIn
Domain includes | wotsec:APIKeySecurityScheme |
IRI: https://www.w3.org/2019/wot/security#flow
Domain includes | wotsec:OAuth2SecurityScheme |
IRI: https://www.w3.org/2019/wot/security#format
Domain includes | wotsec:BearerSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#identity
Domain includes | wotsec:PSKSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#in
Domain includes | wotsec:BasicSecurityScheme wotsec:BearerSecurityScheme wotsec:DigestSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#name
Domain includes | wotsec:APIKeySecurityScheme wotsec:BasicSecurityScheme wotsec:BearerSecurityScheme wotsec:DigestSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#in
Domain includes | wotsec:BasicSecurityScheme wotsec:BearerSecurityScheme wotsec:DigestSecurityScheme wotsec:PoPSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#name
Domain includes | wotsec:APIKeySecurityScheme wotsec:BasicSecurityScheme wotsec:BearerSecurityScheme wotsec:DigestSecurityScheme wotsec:PoPSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#proxy
Domain includes | wotsec:SecurityScheme |
Range includes |
IRI: https://www.w3.org/2019/wot/security#qop
Domain includes | wotsec:DigestSecurityScheme |
IRI: https://www.w3.org/2019/wot/security#scopes
OAuth2SecurityScheme
active on that form. Domain includes | wotsec:OAuth2SecurityScheme |
No AnnotationProperty found in the ontology.
OAuth2SecurityScheme
active on that form.