[This specification provides a selection of well-established security mechanisms] (that are or ).
この仕様は、W3C WoTのプロトコルバインディングとして適しているプロトコルに直接組み込まれる、またはそのプロトコルで広く用いられる、確立されたセキュリティメカニズムの選択について規定している。
The current set of HTTP security schemes is partly based on OpenAPI 3.0.1 (see also [OPENAPI]). However while the HTTP security schemes, Vocabulary, and syntax given in this specification share many similarities with OpenAPI, they are not compatible.
現在のHTTPセキュリティスキームは、部分的にOpenAPI 3.0.1に基づいている ([OPENAPI] も参照)。しかし、この仕様で示しているHTTPセキュリティスキーム、語彙、および構文は、OpenAPIと多くの類似点を共有しているものの、互換性はない。
A security configuration corresponding to identified by the Vocabulary Term nosec (i.e., "scheme": "nosec"), indicating there is no authentication or other mechanism required to access the resource.
nosecという語彙用語 (つまり、"scheme": "nosec") で識別されるセキュリティ構成情報で、リソースへのアクセスに認証やその他のメカニズムが必要ないことを示す。
no xxx needed ではなく no xxx required を区別した方が良いかも?必要ないというと任意の気がするがどちらかというとナシを宣言する印象なので (元訳でも何ら問題は無い)
5.3.3.3 BasicSecurityScheme (基本セキュリティスキーム)
Basic Authentication [RFC7617] security configuration identified by the Vocabulary Term basic (i.e., "scheme": "basic"), using an unencrypted username and password. This scheme should be used with some other security mechanism providing confidentiality, for example, TLS.
basicという語彙用語 (つまり、"scheme": "basic") で識別される基本認証 [RFC7617] セキュリティ構成情報で、暗号化されていないユーザ名とパスワードを用いる。このスキームは、例えば、TLSなどの機密性を提供する他のセキュリティメカニズムとともに用いるべきである。
Digest Access Authentication [RFC7616] security configuration identified by the Vocabulary Term digest (i.e., "scheme": "digest"). This scheme is similar to basic authentication but with added features to avoid man-in-the-middle attacks.
digestという語彙用語 (つまり、"scheme": "digest") で識別されるダイジェストアクセス認証 [RFC7616] セキュリティ構成情報。このスキームは基本認証に似ているが、中間者攻撃 (man-in-the-middle attack) を回避する機能が追加されている。
39 とか #41 などで議論、修正が続いている悩みどころの 5.3.3.x の文章について長く議論していてもどうしても収まり悪かったのでしっかり考えてみた結果をまとめます (いくつか分けて PR 作るべき所ですがひとまずまとめて議論出来るように issue にて)。
xxxxx identified by the Vocabulary Term yyyyy のところはそもそも yyyyy (nosec とか basic など) が Vocabulary Term ではないという結構致命的な間違いのある原文だというのが最大の問題ではないかと。
以下 https://hackmd.io/@wot-jp/translation-td-dynamis に書き残しているメモのスナップショットより:
5.3.3 セキュリティ語彙の定義
https://wot-jp-community.github.io/wot-thing-description/index.html#sec-security-vocabulary-definition
⇒ この仕様では十分確立された既存セキュリティメカニズムの選択について規定しており、W3C WoT のプロトコルバインディングとして適したプロトコルに直接組み込まれるものと、それらのプロトコルで共に広く用いられているものの両方を対象とする。
⇒ 現在のHTTPセキュリティスキームの集合は、部分的にはOpenAPI 3.0.1を元に規定しており ([OPENAPI] も参照)、OpenAPIと多くの類似・共通点はあるが、この仕様で示しているHTTPセキュリティスキーム、語彙、および構文にOpenAPIとの互換性はない。
5.3.3.2 NoSecurityScheme (セキュリティスキームなし)
一連の xxxxx identified by the Vocabulary Term yyyyy の訳が日本語として読みにくいのをどうにかしたい問題
⇒ (直訳) "scheme": "nosec" のように nosec という語彙用語で識別するセキュリティ構成情報。リソースへのアクセスに認証やその他のメカニズムを要求しないことを示す。
⇒ (原文の誤り訂正) "scheme": "nosec" のように scheme 語彙用語を指定するセキュリティ構成情報。nosec はリソースへのアクセスに認証やその他のメカニズムを要求しないことを示す。
5.3.3.3 BasicSecurityScheme (基本セキュリティスキーム)
⇒ "scheme": "basic" のように scheme 語彙用語を指定する、基本認証 [RFC7617] セキュリティ構成情報。暗号化されていないユーザ名とパスワードを用いる。このスキーマは、例えば TLS などの機密性を提供する他のセキュリティ機構と共に用いるべきである。
5.3.3.4 DigestSecurityScheme (ダイジェストセキュリティスキーム)
⇒ "scheme": "digest" のように scheme 語彙用語を指定する、ダイジェストアクセス認証 [RFC7616] セキュリティ構成情報。このスキーマは基本認証に似ているが、中間者攻撃 (man-in-the-middle attack) を回避する機能が追加されている。