1. 序論
~webに公表された情報への~accessを制御するために広く用いられている手法には、 次の 2 つがある： ◎ There are two broad methods of controlling access to information that is published on the web:
- ~serverは、 ~access制御~保護策を有し得る — 内容に~accessしている人々に［ ~access可能になる前に，正しい~token（たち）（~passwordや~cookieなど）を供する ］よう要求するような。 ◎ the server can have access control measures that require people accessing the content to provide the correct token(s) (such as a password or cookie) before the content is accessible
- 情報は［ 隠蔽された／推測-不能な ］~URLにて公表され得る — その情報への~linkは、 情報への~accessが許可された人々に限り供される。 ◎ the information can be published at an obscure or unguessable URL, and links to it only provided to people who have permission to access it
後者の手法に利用される~URLは、 `能力~URL@ （ `capability URLs^en ）として知られている： ~URLを所持している~agentには、 当の情報に~accessする能力が与えられる。 ◎ The URLs used in the second method are known as capability URLs: an agent who possesses the URL is given the capability to access the information.
~accessを制御するこれらの手法は、 組合nで利用できる。 例えば，［ ある~form提出により作成される~URLの中の~sessionに特有な~token（能力~URLの一種） ］は、 `~CSRF＠https://en.wikipedia.org/wiki/Cross-site_request_forgery$ に抗して保護する助けになる — 第三者-主体~pageが［ ~target~pageに~accessするために必要yな~cookieを利用者が有している事 ］による有利をとれる所で。 ◎ These methods of controlling access can be used in combination. For example, a session-specific token within the URL created by a form submission (a type of capability URL) helps to protect against cross-site request forgery where third-party pages can take advantage of the fact that a user has the necessary cookie to access a target page.
この文書は、 次について述べる： ◎ This document describes:
- 能力~URLが今日の~webの~~現場で利用されている例 ◎ examples where capability URLs are used on the web today
- 内容への~accessを制御するために能力~URLを利用する際の，有利と不利 ◎ advantages and disadvantages of using capability URLs to control access to content
- 能力~URLを利用する~web~siteを作成する際の，設計の考慮点 ◎ design considerations when creating websites that use capability URLs
- 能力~URLの利用を~supportする技術-開発の分野 ◎ areas of technical development to support the use of capability URLs
- ~URLを秘匿に保つことに関係する課題 ◎ Issues relating to keeping URLs secret
2. 能力~URLの例
能力~URLは、 広範に利用されている。 この節では、 能力~URLが~webで利用されている~~現場からの例を包含する。 ◎ Capability URLs are in widespread use. This section contains examples from the web where capability URLs are used.
2.1. ~passwordを設定し直す
利用者が~siteに~accessするための~passwordを忘れたとき、 ~siteは，単純に その~passwordを利用者に伝えるわけにはいかない — そうするのは，それらの~passwordを平文~textとして格納して伝送することを~siteに要求することになり，極めて~secureでなくなるので。 ◎ When a user forgets their password to access a site, the site cannot simply tell them what their password is as this would require the site to store and transmit their password as plain text, which is extremely insecure.
代わりに，利用者に~emailを送信する~patternが通例的に利用されている — それは、［ 利用者の~passwordを設定し直すために十分な許可 ］を伴う~linkを，受信した利用者に供する。 ◎ The pattern that is usually used instead is that the user is sent an email that contains a link that provides the user who has received that link with enough permissions to reset their password.＼
次の例は、 ~Dropboxから： ◎ This example is from Dropbox: ◎ Example 1
Your Dropbox password recently expired. You can reset it `here＠https://www.dropbox.com/l/Q8eJH22ft0ckDJDeff1Do10/password_reset$.
（あなたの~Dropbox~passwordは近過去に失効しました。 `ここ^i で設定し直すことができます。）
この事例では、 能力~URLは “`here^en（`ここ^i）” に付与された `https://www.dropbox.com/l/Q8eJH22ft0ckDJDeff1Do10/password_reset^s になる。 この~linkに（失効する前に）~accessしている誰もが，その能力~URLに結付けられた利用者~用の~passwordを変更-可能になる。 ◎ In this case the capability URL is https://www.dropbox.com/l/Q8eJH22ft0ckDJDeff1Do10/password_reset. Anyone accessing this link (before it expires) is able to change the password for the user with whom the capability URL is associated.
2.2. ~Second-Life
Reg API capabilities represent permissions to perform certain actions.
（登録~API能力は、 一定の動作を遂行する許可を表現します。）
~Second-Life~APIの中では，~UAには［ 利用者が望む各~動作に伴って，資格証を供すること ］は要求されない。 代わりに，~UAは~usernameと~passwordを伴う単独の~formを提出する — 対する応答は，各種 能力~用に一連の能力~URLを包含する。 例えば： ◎ Within the Second Life API, user agents aren't required to provide credentials with each action that they wish to take. Instead, they submit a single form with a username and password and the response contains a set of capability URLs for different capabilities. For example:
◎ Example 2
<llsd>
<map>
<key>create_user</key>
<string>https://cap.secondlife.com/cap/0/35ff3b8c-a30d-4d18-b29a-e3f7f6c79cb6</string>
<key>check_name</key>
<string>https://cap.secondlife.com/cap/0/6e528ba1-a8b0-4f6b-8b56-362ee6f5cef8</string>
<key>get_last_names</key>
<string>https://cap.secondlife.com/cap/0/be4e4d2e-c00a-46cd-bb8d-d17cb8e92c9b</string>
<key>get_error_codes</key>
<string>https://cap.secondlife.com/cap/0/e75f81a5-b7da-4480-8f95-b1cf9d2d680f</string>
</map>
</llsd>
文書化は、 これらの能力~URLを利用するための指針として，次の 2 つを供する： ◎ The documentation provides two guidelines for using these capability URLs:
Do not hard-code your capabilities URLs. Either code your capabilities URLs as constants, or better yet, obtain them at run-time. Capability URLs will expire eventually, so fresh ones are always better.
（ 能力~URLは、 ~codeに直書きしないでください。 能力~URLは、 【それを代理する】定数として~code化するか，稼働時に得る方がさらに良いです。 能力~URLは、 最終的には失効することになるので，新鮮な方が常に良いです。 ）
Keep your capability URLs secret! The capabilities granted to you are only meant for you. A capability URL is sensitive much like a password. Moreover, Linden Lab tracks the use of each capability.
（ 能力~URLは、 秘匿に保ってください。 あなたに是認される能力は、 あなた用に限られるものと意味されています。 能力~URLは、 ~passwordにほぼ~~等しく敏感です。 さらには、 ~Linden-Labは各~能力の利用を追跡します。 ）
2.3. ~Google-Calendar
~Google-Calendarは、 ~calendarの［ ~XML／~iCalendar ］形式~用に私用~address（ `Private Address^en ）を供する。 これらは、［ ~feed-reader／~calendar~program ］の中で ~calendarへの~accessを供するためとして，誰でも利用できるが、 利用者には警告される：
"Your calendar's Private Address was designed for your use only, so be sure not to share this address with others."
（あなたの~calendarの私用~addressは，あなたの利用~用に限り設計されたものです。 この~addressを他者と共有しないでください。）
（ `“私用~address” について＠https://support.google.com/calendar/answer/37106?hl=en&ref_topic=1672529$ から~~引用）
◎ Google Calendar provides Private Addresses for XML and iCalendar formats of a calendar. These can be used by anyone within a feed reader or a calendar programme to provide access to the calendar, but users are warned "Your calendar's Private Address was designed for your use only, so be sure not to share this address with others." (from About the 'Private Address').私用~addressに結付けられた~helpは、 同様に，~URLを他者と共有しないよう警告する： ◎ The help associated with Private Addresses similarly warns against sharing the URLs with others:
~help~boxの一節：
あなたの~calendarの私用~addressは、
あなたの利用~用に限り設計されています。
あなたの~calendarを成すすべての情報は、
あなたの私用~linkを介して可用になるので、
この~addressを他者と共有しないでください。
私用~addressを変更して，これまでの~accessを不能化したい場合は、
“私用~URLを設定し直す（ `Reset Private URLs^en ）”
~linkを~clickしてください。
◎
Help box reading 'Your calendar's Private Address is designed for your use only. All of your calendar information is available via your private links, so don't share this address with others. To change your Private Address and disable any previous access, click the Reset Private URLs link.'
2.4. ~GitHub~Gist
~GitHub~Gistは、 ~version付き~codeその他の~fileを他の人々と共有して論じることを~supportする。 これらは、 匿名で作成でき，私的に保てる。 私的な~Gistへの~accessは、 単純に当の~Gist用の~URLを共有することを通して供される。 ◎ GitHub Gists support sharing and discussing versioned code and other files with other people. These can be created anonymously, and can be kept private. Access to private Gists is provided simply through sharing the URL for the Gist.
~Gist~pageは~pop-upで次を説明している：
秘匿な~gistは、
探索~engineからは隠されますが，あなたが~URLを与えた誰からも可視になります。
◎
Gist page with a pop-up explaining 'Secret gists are hidden from search engines but visible to anyone you give the URL.'
2.5. ~Doodle~poll
~Doodleは、［ 利用者が~log-inすることなく~URLを通して~accessできる~pollを作成すること ］を利用者に可能化する。 当の~pollの管理者には、 ~browserの中, および~emailを通して~URLが供される。 例えば： ◎ Doodle enables users to create polls that can be accessed through URLs without users logging in. The URLs are provided to the administrator of the poll within the browser and through email. For example:
~Doodle~pageは、 次の~URLを供している：
-
参加~link（ `Participation link^en ）には、
次の文言を添えている
⇒
招待したい人に この~linkを送信してください。
-
管理用~link （ `Administration link^en ）には、
次の文言を添えている
⇒
この~pollを［ 変更する／閉じる／削除する ］ときは、 この~linkに~accessしてください。
2.6. ~Flickr画像
~Flickr上の私的な画像は、 ~Guest-Passを通して共有できる — それは、 所与の画像~用に その場で生成される。 ◎ Private images on Flickr can be shared through Guest Passes which are generated for a given image on demand.
~Flickr~dialogでは、
~Guest-Pass用に
~linkをつかむ（ `Grab the link^en ）
文言を添えて，利用者を~Guest-Pass履歴に訪問するよう招待する。
◎
Flickr dialog saying 'Grab the link' for a Guest Pass and inviting the user to visit the Guess Pass History.
利用者は、 ~Guest-Pass履歴を閲覧vできる。 それは、 当の画像~用に現在の~Guest-Passを失効させる~optionを供する。 ◎ Users can view the Guest Pass History which provides the option of expiring the current Guest Pass for the image.
~Flickr上の~Guest-Pass履歴の一部分。 ~Guest-Passを失効させる~optionを示している。 ◎ Portion of a Guest Pass History on Flickr, showing the option to Expire the Guest Pass.
2.7. ~Tahoe-LAFS
~Tahoe-LAFSは、 ~open-cloud~storage~systemを供する。 それは、 ~fileへの~accessを管理するため `能力に基づく~HTTP~server＠https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst$ を利用する。 例えば，次のような~URLは、 ~Tahoe-LAFSの中に格納された ある~fileへの~accessを読み取りに限り供する： ◎ Tahoe-LAFS provides a open cloud storage system that uses capability-based HTTP servers to manage access to files. For example, a URL such as:
https://zooko.com/uri/URI:DIR2-MDMF-RO:dwvqalbdt4ax4vgupcewxljg3u:bej7hhojmpuugy77oyydmazf6uu7huiipkctih7adky7e6txavnq/klog.html
`~REST~APIの全部的な文書化＠https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst$ は、 この例が含む `URI:DIR2…^s などの能力が［ ~URLの中で, および各種~HTTP~methodと伴に ］どう利用されるかを述べる。 それは、［ ~file, ~directory ］どちらの能力か, および［ 検証y-のみ, 読み取りのみ, 読み書き ］のうちどの能力かを判別する。 ◎ provides read-only access to a file stored within Tahoe. The full REST API documentation describes how capabilities such as URI:DIR2:djrdkfawoqihigoett4g6auz6a:jx5mplfpwexnoqff7y5e4zjus4lidm76dcuarpct7cckorh2dpgq are used within URLs and with different HTTP verbs. It distinguishes between file capabilities and directory capabilities, and between read-write, read-only and verify-only capabilities.
3. 能力~URLを利用する理由
上に述べた例から明らかにされた，能力~URLを利用する~rationaleには、 以下の各~下位節に挙げる 4 つがある。 ◎ There are four rationales for using capability URLs evident in the examples described above.
3.1. ~loginは要求されない
能力~URLは、 利用者が~serviceに~accessすることを，その~serviceへの~loginや~password抜きに可能化する。 それが特に有利になる状況として，次が挙げられる： ◎ A capability URL enables a user to access a service without having a login or password on that service. There are three situations where that is a particular advantage:
- 利用者が~loginの詳細を思出せないとき ◎ users who can't remember login details
- 利用者が~accountを作成したいと求めないとき ◎ users who don't want to create accounts
- 開発者が~accountを~supportしたいと求めないとき ◎ developers who don't want to support accounts
3.1.1. ~passwordを忘れたとき
利用者が~passwordを忘れることは頻繁にある — とりわけ、 その形が 包含する文字の長さや種別に基づいて制約されているとき。 次の~~理由から，~passwordを忘れた利用者に~passwordを送信するときは、 ~URLを送信する方が好ましい： ◎ Users frequently forget their passwords, especially when their form is restricted based on length or types of characters that they contain. Sending a URL to users who forget their passwords is preferable to sending a password because:
- ~passwordの送信は、 ~passwordを平文~textで送信する（場合によっては格納する）ことを~web~siteに要求することになり、 不良な~securityの実施である。 ◎ sending a password would require the website to send (and possibly store) the password in plain text, which is a bad security practice
- 能力~URLは、 ~accessされた後に失効し得る／させれる — それは、 当の~emailや~URLが後で共有されても，~accountへの~accessを それ以降は供さないことを意味する。 ◎ the capability URL can expire after it has been accessed, which means that even if the email or URL is shared later on, it doesn't provide ongoing access to the account
- 能力~URLは、 利用者に~passwordを設定し直すよう強制する~pageに解決できる。 単純に利用者に~passwordが呈示された場合や, ~URLで~system全体への~accessが是認された場合、 利用者は，~passwordを設定し直すのを思出してくれないかもしれない。 ◎ the capability URL can resolve to a page that forces the user to reset their password; if users were simply presented with a password or granted access to the entire system with the URL then they might not remember to reset their password
3.1.2. 手軽な~account
利用者が自身の~account用に自身の選好や履歴を記録する助けを供するような，~webに基づく~serviceは急増している。 利用者にとっては、 別の~accountを作成することは — 特に，その~accountを頻繁に利用するものと期待しないときには — 高い負担になり得る。 ◎ There are a proliferation of web-based services which provide for user accounts, to help record user preferences and history. Creating another user account can become a high burden for users, particularly when they don't expect to use the account very frequently.
~webに基づく~appのうち，利用者~情報を要求することなく機能するものは、 利用者が~accountを作成することなく~serviceへの~accessを可能化したり，利用者が しばらくの間~serviceを利用した後に限り，~accountを作成するよう利用者に~promptすることができる。 ◎ Web-based applications that do not require user information in order to function may enable users to access the service without creating an account, or only prompt the user to create an account after they have used the service for a while.
能力~URLを利用することは、 ~webに基づく~appの常連~利用者にとって，有益になる — ~serviceの常連でない人々と協同することを可能化するので。 常連~利用者は、 資源を作成してから，資源~用の~URLを別の~route（例：~email）を通して協同者と共有できる。 ◎ Using capability URLs is beneficial to the more regular users of a web-based application because it enables them to collaborate with other people who are not regular users of the service. Regular users can create a resource and share a URL for that resource with their potential collaborators through another route (eg through email).
能力~URLのうち［ ~accountを要求することなく，協同を手助けする ］ために利用されるものは、 一般に 常連~利用者により制御される — その者は，次を望むこともあろう： ◎ Capability URLs that are used to facilitate collaboration without requiring accounts are generally controlled by a regular user, who might wish to:
- 協同したいと望む［ 人々／~group ］ごとに，異なる能力~URLを作成する。 ◎ create different capability URLs for different people or groups that they wish to collaborate with
- 資源に許可したいと望む動作の種別ごとに（例： 編集-用／~comment用／閲覧v用 ），異なる能力~URLを作成する。 ◎ create different capability URLs for different types of action that they wish to permit on a resource (eg editing or commenting or viewing)
- 意図された~groupの外側で共有されたものと察知した場合に備えて、 当の能力~URL用の許可を廃止-可能にする。 ◎ be able to revoke permissions for given capability URLs if they learn they have been shared outside the intended group
3.1.3. ~accountを伴わない~web~site
~account管理が~webに基づく~appの主な目標になることは、 滅多にない。 ~account管理を組み込むのは，開発者にとって比較的~容易ではあるが、 そこには~overheadが孕まれ得る： それには、 ~securityの懸念が提起され得ることに加え，個人-~dataの格納-法を孕むことによる法的な含意がある。 ◎ Account management is seldom the main goal of a web-based application. Although it can be relatively easy for developers to plug in account management, there is an overhead involved: it can raise security concerns, and has legal implications because it involves storing personal data.
~appには、［ 利用者に属する重要な作業を，他の誰かが削除する~risk ］は無いものもある — 当の~web~appが，［ 重要な作業を行うために利用されていない／ 破壊的な動作-を~supportしない ］ときなど。 ◎ In some applications there is no risk of someone else deleting important work belonging to another user. This might be because the web application is not used to do important work. Or it might be that the application does not support destructive acts.
これらの事例では、 ~web~appの開発者は — ~account管理よりも，~appの主~目的の開発に注力できるよう — 利用者~accountは~supportしないで，能力~URLを利用することにするかもしれない。 ◎ In these cases, it may be that the developer of a web application chooses to use capability URLs rather than supporting user accounts, letting them focus development on the main purpose of the application rather than account management.
3.2. ~sandbox化された~domainに対する~accessの管理-法
信用されない利用者からの内容を~hostする~siteには、 その内容を利用者ごとに別々な~domainの中に~sandbox化するものもある。 これは、 利用者により管理される内容には，［ 同一-生成元にあることにより，通例的に授けられる特権 ］は是認されないことを確保する。 ◎ Sites that host content from untrusted users sometimes sandbox that content within separate per-user domains. This ensures that content managed by users isn't granted the privileges that are usually conferred by being on the same origin.
しかしながら，これらの事例では、［ 利用者に特有な~domainに属する私的な内容への~access ］を［ 当の~main~siteに利用者が有する，通常の認証~cookieを複製する ］ことを通して制御することはできない — そのような~cookieは、 ~sandboxへ通じる~routeを与えることになるので。 代わりに、 `文書ごとの能力~URLが，代替な認証の仕組みを供し得る＠https://security.googleblog.com/2012/08/content-hosting-for-modern-web.html$ 。 ◎ In these cases, however, access to private content on the user-specific domain cannot be controlled through copying the normal authentication cookies that the user has on the main site, because those cookies would give a route through the sandbox. Instead, per-document capability URLs can provide an alternative authentication mechanism.
3.3. 容易な委任
能力~URLを~supportする理由の一つは、 それが［ ~accessを元々共有していた者が，その~accessを自前の~networkで共有し続ける ］ことを可能化することにある。 ◎ A second set of reasons for supporting capability URLs is that it enables those with whom access is originally shared to continue to share that access with their own network.
例えば，組織どうしの会合を手配しようと試行している ある利用者は、［ 会合に出席するべき他の組織の人々 ］全員は知らないかもしれない。 通常の~accountに基づく手法の下では、 その利用者は概して — ~systemへの~accessを，それら各個人に是認する前に — 誰が会合に出席するべきなのか情報を集める必要が生じる。 能力~URLであれば、 各~組織からの代表者と~URLを共有して，その代表者を信用するだけで済む — 各~代表者は、 誰であれ，~~参加する必要がある同僚に~URLを渡すことになる。 ◎ For example, if a user is trying to arrange a meeting between organisations, they might not know all the people who should attend the meeting from other organisations. Under a normal account-based method, the user would typically have to gather the information about who should attend the meeting before granting each of those individuals access to the system. With a capability URL, they only have to share the URL with a representative from each organisation, and trust that representative to pass on the URL to whichever colleagues need to take part.
したがって，能力~URLは、 ~accountに基づく~systemが行えるより容易に，~networkを通して許可を流すことを可能化できる。 ◎ Capability URLs can thus enable permissions to flow through networks more easily than they can with an account-based system.
3.4. 容易な~client~API
~HTTP~APIにおける認証は、 重荷になり得る — ~HTTPは，~statelessな~protocolであり、 各~transaction上で認証~tokenを渡して処理することが要求されるので。 これは，帯域幅も処理~力も~~費やすので、 小さな~messageが頻繁に行き交うことを孕む~APIにとっては，有意な~overheadにもなり得る。 ◎ Authentication can be burdensome in HTTP APIs because HTTP is a stateless protocol and requires authentication tokens to be passed and processed on each transaction. This takes up both bandwidth and processing power, which can be a significant overhead for APIs that involve frequent, small, messages.
そのような場合、 能力~URLを利用できる。 ~clientは： ◎ Capability URLs can be used instead. Clients:
- 認証を通常通り遂行して， ◎ perform authentication as normal
- 当の~session用に以降で利用する能力~URLの~listを要請して， ◎ request a list of capability URLs to use for the rest of the session
- それらの~URLを，認証を伴わずに利用する。 ◎ use those URLs without authentication
これは、 交換を相応に~secureに保ちながら，各~transactionから認証~costを除去する。 ◎ This removes the authentication cost on each transaction while keeping the exchanges fairly secure.
注記： ここには、［ 頻繁に行き交う小さな~message ］用に~HTTPを利用することについて，より大きな課題がある。 【これは、 HTTP/2 や HTTP/3（多重化を~supportする~HTTP）には`該当しない＠https://github.com/w3ctag/capability-urls/issues/3$。】 ~HTTPは，これらの状況下では、 適切な~protocolとは紛れもなく言えず，他の対処法 — ~long-pollingや~pipeline化された要請など — の方がより良く働くことになろう。 ◎ Note There are larger issues here about using HTTP for frequent, small, messages. Arguably, HTTP isn't an appropriate protocol in these circumstances, or other workarounds such as long polling or pipelined requests would work better.
4. 課題になり得るもの
~URLは、 元々，秘匿~情報を包含するように設計されてはいない。 能力~URLを利用することには、 その事から発生している不利がある。 ◎ There are disadvantages to using capability URLs arising from the fact that the URLs were not originally designed to contain secret information.
4.1. 公開の~risk
4.1.1. 公開~riskの分析
一般に，~URLを利用する~appは、 それらを敏感な情報として扱うよう設計されてはいない。 ~URLは、 ~URL~barの中に現れるので，~URL~barを見た人々により容易に複製され得る（例えば，呈示の間や誰かの肩越しに）。 ~URLは、 ~web~serverや~browser履歴の中など，~app~logの中にも平文~textで現れる。 ◎ In general, applications that use URLs are not designed to treat them as sensitive information. URLs appear within URL bars, from which they can be copied by people who see the URL bar (for example during a presentation or over someone's shoulder). They also appear in plain text within application logs, such as within web servers and in browser history.
もっと微妙な公開~routeもある。 能力~URLを通して~accessされた~pageにある別の~siteへの~link — 画像や~scriptなど，自動的に追従される~linkも含む — を追った場合、 その~siteには， `Referer$h ~HTTP~headerを通して能力~URLについて通知され得る。 能力~URLを通して~accessされた ある~pageの中の第三者-主体~scriptは、 その~URLに~accessでき，それを他所に記録することもあり得る。 ［ ~browser履歴と~browser~plugin~toolbarを同期するように~hostされる~service ］は、 それを利用している誰かが訪問した~page用の~URLを容易に入手できる。 ◎ There are more subtle routes for exposure too. If a link to another site, including automatically followed links such as to images or scripts, is followed on a page accessed through a capability URL, that site may be notified of the capability URL through the Referer HTTP header. Third party scripts within a page accessed through a capability URL can access that URL and potentially record it elsewhere. Hosted services that synchronise browser histories and browser plugin toolbars can easily get hold of URLs for pages that someone using them visits.
利用者が能力~URLを初めて取得するときの手法も、 弱体化され得る — その結果、 ~ISPや~webに基づく~email~serviceが，~URLに気付くことを可能化する。 能力~URLは、 ~Twitterの~direct~messageを介して共有された場合には， `t.co^s などの~URL短縮化~serviceにも公開されることになる。 ◎ The method by which a user gets the capability URL in the first place may also be compromised, enabling an ISP or web-based email service to become aware of the URL. Capability URLs will also be exposed to URL shortening services such as t.co if they are shared via Twitter direct messages.
~browserの~URL~barが探索~engineへの~accessも兼ねている場合、 そこにコピペされた能力~URLは，~browserが それを~URLでないと誤って認識した場合（例えば，うっかり空白が追加されたため），探索~engineに渡され得る。 ◎ In browsers where the URL bar also provides access to search, a copied capability URL can be mistakenly be passed through to a search engine, if the browser doesn't recognise that it is a URL (for example because of accidentally added whitespace).
いくつかの~browserは、 ~phishingを検出する — それら【どれ？】を通して~accessされた~URLを中央-~serverへ戻るよう送信することにより。 ~browserにとっては、 特定0の~URLが能力~URLであることを知る仕方は無いので、 これらは，~browser~vendorが制御する中央-~serverへ戻るよう送信される。 ◎ Several browsers detect phishing by sending URLs that are accessed through them back to a central server. As there is no way for a browser to know that a particular URL is a capability URL, these are also sent back to a central server controlled by the browser vendor.
これらの~URLの~sourceは、 どれも，探索~engineや他の~crawlerにより利用され得る — その結果、 能力~URLを通して保護された~pageが，探索~結果の中に示されることにもなり得る。 ◎ Any of these sources of URLs can be used by search engines and other crawlers, and may therefore result in pages protected through capability URLs being shown within search results.
短く言えば、 能力~URLの公開による~riskは — 特に，~browserを通して~accessされるときには — 安全策を講じておかない限り，かなり高くなり得る。 ◎ In short, the risk of exposure of capability URLs can be quite high, particularly when they are accessed through a browser, unless safeguards are put in place.
4.1.2. 公開の~riskがある局面
能力~URLの共通的な利用において発生する問題のいくつかを，以下に挙げる例で~~説明する。 ◎ The following examples illustrate some problems that arise in common uses of Capability URLs.
能力~URLは、 公な文書~管理~systemにより作成され，相応しく~secureな手段を介して文書の作者へ伝達される。 作者は、 その~URLを友人に~emailする — 文書に~accessできるのは、 ~emailの受信者に限られるものと期待して。 ◎ A capability URL is created by a public document management system and conveyed via suitably secure means to the author of the document. The author then emails the URL to a friend, expecting that only the recipient of the email will have access to the document.
実施においては、 ~URL転送の~securityは，［ 送信器から受信器への~pathにある~emailの取扱い, および 受信されたとき何が起こるか ］に依存することになる。 伝送~routeを成すある部位には，暗号化されない~protocolが利用されるかもしれず（例：暗号化されない~POP3~link）、 文書に攻撃者を駆立てるに足るほど価値がある場合，攻撃者は~linkを~sniffして~URLを検索取得するかもしれない。 ~emailは，様々な通過点で~queue内に~bufferされるかもしれず、 それらの~queueは，~email転送~systemの管理者から可視になるかもしれない。 ~emailを受信した友人は，その~emailを適度に~access不能な場所に格納するかもしれないが、 遂には他者に読まれ得るような，暗号化されない~email~backupも作成するかもしれない。 ◎ In practice, the security of the URL transfer will depend on the handling of email on the path from the sender to receiver, and what happens to it once received. Unencrypted protocols might be used on some portions of the transmission route (eg an unencrypted POP3 link), and if the document were of sufficient value a motivated attacker might sniff the link to retrieve the URL. The email might be buffered in queues at various points in transit, and those queues might be visible to administrators of the email transfer systems. The friend receiving the email might store her email in a reasonably inaccessible place, but might create unencrypted email backups that could eventually be read by others.
~passwordを設定し直す~siteは — そのような~riskを軽減するべく — そのために利用-可能な能力~URLを~emailした上で， 15 分の制限時間を課す — ~URLは、 それ以降は受容されなくなる。 ◎ Seeking to mitigate such risks, a password reset site emails a capability URL usable for password reset, but imposes a 15 minute timeout after which the URL is no longer accepted.
この時間枠は、 多くの局面で，~~実際に受容-可能な~securityを供することになるが、 当の~passwordが攻撃者を駆立てるに足るほど高~価値な~system用のものであれば、 攻撃者は，この時間枠の中で~URLを~sniffして利用する手はずを整えるかもしれない。 ◎ For many scenarios the timeout window will indeed provide acceptable security, but if the password is for a sufficiently high-value system, a motivated attacker might arrange to sniff and use the URL within the timeout window.
能力~URLを配備するときは、 対抗策が~appの要件に適切になることを確保すべく，これらの~riskを分析することが本質的である。 一部の~appにとっては、 能力~URLは，必要に足る~securityを供さない。 ◎ It is essential when deploying capability URLs to analyze risks such as these and to ensure that countermeasures are appropriate to the requirements of the application. For some applications, capability URLs will not provide sufficient security.
4.2. 弱体化の取扱い
能力~URLが求まれない受信者に漏洩した場合、 それを通した~accessを元々是認した個人が，その~URLを廃止-可能になる必要がある。 これは、 通常の~account駆動な~access制御で起きた場合に必要yなものと正確に同じになる。 しかしながら，能力~URLは、 所与の能力を有する誰にとっても同じになるよう設計される傾向にあるので、 能力~URLを廃止すると，それを有する者すべてに影響iがある。 逆に，~accountに基づく~access制御は、 単独の利用者を対象に~access権を撤回することがアリになる傾向にある。 ◎ If a capability URL does leak out to unwanted recipients, the person who originally granted access through that URL needs to be able to revoke it. This is exactly the same as needs to happen in normal account-driven access control. However, capability URLs tend to be designed to be the same for everyone who has the given capability, and therefore revoking the capability URL has an impact on all those who had it. Conversely, in account-based access control it tends to be possible to target the withdrawal of rights on a single user.
能力~URLを もっと対象を絞る仕方で利用するよう~systemを設計することもアリである — 同じ能力~用に複数の~URLを生成することを利用者に可能化して、 それぞれを異なる人々に渡すことにより。 これは、 特定0の~URLが弱体化されたときに，~access権の廃止を当の対象に限ることを可能化することになろう。 ◎ It is possible to design systems that use capability URLs in a more targetted way, enabling users to generate multiple URLs for the same capability and to pass those on to different people. This would enable targetted revocation of access rights when a particular URL is compromised.
4.3. ~web~architecture
能力~URLは、 資源とその資源~用の~access特権の組合nを符号化する。 これは、 別々な~URLが同じ資源を指すために利用されることへ導く （が、それで何が行えるかについては，異なる許可を伴うような）。 例えば，~Google-Calendarは、 ~calendarの同じ~iCalendar表現~用に［ 公な利用, 私的な利用 ］用として異なる~URLを供する。 ◎ Capability URLs encode a combination of a resource and access privileges for that resource. This leads to separate URLs being used to refer to the same resource (but with different permissions about what can be done with it). For example, Google Calendar provides different URLs for the same iCalendar representation of a calendar for public and private use.
同じ資源~用に複数の~URLを利用することは、 良な実施 （ `Architecture of the World Wide Web, Volume One＠~TR/webarch/#avoid-uri-aliases$【！ ~web~architecture 第 1 巻】） に反するようにも見える：
良な実施：別名~URIは避けること。 ~URI所有者は、 同じ資源に任意に異なる~URIを結付ける`べきでない^em。◎ Using multiple URLs for the same resource appears to run contrary to good practice: • Good practice: Avoiding URI aliases A URI owner SHOULD NOT associate arbitrarily different URIs with the same resource. • Figure 8 Architecture of the World Wide Web, Volume One
しかしながら，この推奨の~rationaleは、 主に~URIの共有に基づいている： 同じ資源を同じ~URLで指す方が，より~~統一のとれた~networkを作成するので — 誰にとっても，~linkするにも, それについて何か言うにも — 良くなる。 能力~URLは、 通常の~URLと違って，制限された共有に限る方へ指向する。 そのような状況下においては、 別名が複数あることは課題にならない。 ◎ However, the main rationale for the recommendation to avoid URI aliases is based on sharing of the URI: it is better for everyone linking to, or talking about, the same resource to refer to it with the same URL, as this creates a more coherent network. Unlike normal URLs, capability URLs are oriented around only limited sharing. In these circumstances, having multiple aliases is not an issue.
しかしながら，［ 資源への~accessを能力~URLを通して供することから，通常の~URLを利用する公な~URLへ遷移する方法 ］については、 考慮される必要もあろう。 これは、 `§ 正準的~URL＠#canonical-urls$にて更に論じられる。 ◎ What may need to be considered, however, is how to transition from providing access to a resource through capability URLs and taking it public, using a normal URL. This is discussed further in § 5.4 Canonical URLs.
4.4. 単独の~pageを超える
`§ 能力~URLの例＠#examples$にて述べた，能力~URLの例は、 どれも自己完結的である： 利用者が能力~URLを通して~pageに~accessしたなら、 利用者は，その~pageの中で行う必要があるすべてを行える。 利用者が複数の~pageに~accessすることを要求するような~appにおいて，能力~URLを利用するのは、 さほど容易でない — それらを成す各~pageは、 それぞれに異なる秘匿を包含する能力~URLを通して~accessされなければならないので。 ◎ All the examples of capability URLs described in § 2. Example Capability URLs are self-contained: once a user has accessed a page through a capability URL, they are able to do all they need to do within that page. Capability URLs are less easy to use in applications that require the user to access multiple pages, because each of those pages must be accessed through a URL that contains a different secret.
~Tahoe-LAFSは、 所与の~directoryが［ その~directoryの中のすべての下位資源への~accessを是認するような能力~URL ］を備える~patternを利用する — 次の様な： ◎ Tahoe-LAFS uses a pattern whereby directories have capability URLs that grant access to all subresources within that directory, using a pattern like:
http://example.org/${DIR-CAPABILITY}/path/to/resource
これは、 その~directoryの中の資源~間の~linkを，一意な能力~keyを埋込まない相対~linkにできることを確保する。 ◎ This ensures that links between resources within that directory can be relative links that do not embed the unique capability key.
5. 推奨
この節では、 能力~URLを~web~appの中で いつ, どう利用するかについて，推奨を要旨する。 ◎ This section outlines recommendations about when and how to use capability URLs within web applications.
5.1. ~appの設計
`§ 能力~URLを利用する理由＠#advantages$では、 能力~URLが有用になる 3 種の状況を要旨した： ◎ In § 3. Reasons to Use Capability URLs we outlined three situations in which capability URLs are useful:
- ある動作を遂行するために，利用者が~log-inする必要を避ける。 ◎ To avoid the need for users to log in to perform an action.
- ~URLを他者と共有するのを容易にする。 ◎ To make it easy for those with whom you share URLs to share them with others.
- ~APIにおける認証~overheadを避ける。 ◎ To avoid authentication overheads in APIs.
能力~URLを利用することを考慮している場合、 他の~optionを考慮して，それを実装する［ ~cost, ~risk, 便益 ］と能力~URLを利用する［ ~cost, ~risk, 便益 ］を天秤にかけるべきである。 例えば： ◎ If you are considering using capability URLs, you should consider other options, and weigh up the costs, risks and benefits of implementing them against the costs, risks and benefits of using capability URLs. For example:
- 代わりに，~accountに基づく仕組みを利用する~accessに制約することもできるか？ ◎ Could access be restricted using an account-based mechanism instead?
- ~HTTP以外の~protocolを利用するべきか？ ◎ Should you use a protocol other than HTTP?
`§ 公開の~risk＠#risk-of-exposure$では、 能力~URLを意図されない発見から保護する難題を強調した。 能力~URLの利用を考慮するときは、 当の~appに要求される~securityを供するため，そのような~riskを必要に足るまで軽減できることを確保するべきである。 次に挙げる推奨される技法は、 多くの事例で，必要十分な~securityを供することになる： ◎ § 4.1 Risk of Exposure above highlights the challenges of protecting capability URLs from unintented discovery. When considering using capability URLs, you should ensure that such risks can me sufficiently mitigated to provide the security required for your application. The following techniques are recommended and will in many cases provide adequate security:
- 能力~URLは、 `https://^c ~URLにするべきである。 これは、 ~URLの公開~すべてを防止するものではないが，その~URLへ向けた~HTTP要請の中で平文~textにて可用にされることは防止する。 ◎ Capability URLs should be https URLs. This does not prevent all exposure of the URL but does prevent it from being available in plain text within the HTTP request for the URL.
- 能力~URLを利用者に伝える~pageは、 ~HTTPSを通して~serveすることにより，暗号化されるべきである。 これもまた、 平文~textによる~URLの伝送を避ける。 ◎ Pages that inform users of capability URLs should be encrypted, by being served through HTTPS. Again, this avoids plain text transmission of the URL.
- 能力~URLは、 失効するべきである。 例えば，［ 能力~URLに~accessし得るのは一度限りにする／ 一週間~経ったら失効するようにする ］ことは、 相応しくなり得る。 ~passwordを設定し直す~linkは、 ~passwordが成功裡に変更されたなら, あるいは~accountの~email~addressが変更されたときは，失効するべきである。 ◎ Capability URLs should expire. For example, it may be suitable to have a capability URL that can only be accessed once, or one that expires after a week. Password reset links should expire after the password has been successfully changed, or when the email address on the account changes.
-
能力~URLを通して~accessされる~pageは、 第三者-主体~web~siteへの~linkを含むべきでない — 当の能力~URLが秘匿~keyを［ ~URLの~pathでなく，素片~識別子 ］に含んでいる場合は除き。 それらは、 他者がそのような~linkを~pageに（例えば，~commentを通して）挿入する仕組みを含むべきでない。 これらが許容される場合、 【そのような~linkから為される要請における】 `Referer$h ~headerの利用を，次のいずれかを利用して管理するべきである： ◎ Pages accessed through a capability URL should not include links to third-party websites, unless the capability URLs include the secret key in the fragment identifier rather than the path of the URL. They should not include a mechanism for others to insert such links onto the page (eg through comments). If these are allowed, the use of the Referer should be managed by:
-
そのような~linkには、
`rel^a="`noreferrer$v"を利用する。 ◎ using rel="noreferrer" on the links - 当の~page用の応答~内に `Referrer-Policy$h ~HTTP~headerを利用して，その値に［ `no-referrer$v ／ `origin$v ／ `origin-when-cross-origin$v ］などを伴わせる。 【！原文誤： Content-Security-Policy: referrer origin】 ◎ using a Content-Security-Policy: referrer origin HTTP header in the response for the page; none or origin-when-cross-origin could be used instead of origin
-
~HTML~pageの中で
<`meta$e `name$a="`referrer$v" `content$a="...">を利用して， `content^a 属性の値に前項に挙げた値を利用する。 【！原文誤： `value^v → `content^a 】 ◎ using a <meta name="referrer" value="origin"> header within the HTML page; again none or origin-when-cross-origin could be used instead of origin
【 すなわち， `Referer$h ~header自体の送信を防止するか，その値が秘匿~keyを含まなくなるようにする。 】【 上の~listにおける原文の記述は、 ~~正確でない（過去の仕様に基づく？）ので，この訳では修正を加えている。 】
-
そのような~linkには、
- 能力~URLを通して~accessされる~pageは、 信用されない第三者-主体~scriptを含むべきでない — ~URLのどの部分が当の秘匿~keyを包含していようが。 ~scriptは、 常に，それが属する~pageの~URLへの~accessを取得できる。 ◎ Pages accessed through a capability URL should not include untrusted third-party scripts, regardless of which part of the URL contains the secret key. Scripts can always get access to the URL of the page they are within.
- 能力~URLが認証-済み利用者により制御される場合、 ［ その利用者が、 自身が制御する資源に結付けられた能力~URLを廃止する ］ことがアリにされるべきである 。 そのような利用者は、 そのような複数個の能力~URLを作成-可能にするべきである — 他の能力~URLからの~accessには影響することなく，弱体化された能力~URLを通した~accessは廃止できるよう。 ◎ If capability URLs are controlled by an authenticated user, it should be possible for that user to revoke the capability URLs associated with the resource that they control. They should be able to create multiple such capability URLs so that they can revoke access through a compromised capability URL without affecting access from other capability URLs.
- 能力~URLの秘匿~keyを成す部分より上位にある~pathは、 `robots.txt^c の中に~listされるべきである — `robots.txt^c を尊守する探索~engineが，それらを~listするのを防止するために。 個々の能力~URLは、 `robots.txt^c の中に~listしないこと。 ◎ The path under which capability URLs are found should be listed within robots.txt to prevent them from being listed by those search engines that honour robots.txt. Do not list individual capability URLs within robots.txt.
- 能力~URLが属する~URL空間への~accessは、 頻度を制限するべきである。 これは、 アリな~URLを列挙することにより，能力~URLを識別しようと試みる攻撃を避ける助けになる。 ◎ Access to the URL space in which capability URLs reside should be rate limited. This helps avoid attacks that attempt to identify capability URLs by enumerating the possible URLs.
能力~URLを利用して関連な動作を可能化するときは、 適切な~HTTP ~methodの中で利用するべきである。 例えば，能力~URLに対する~HTTP `GET$hm による結果は、 資源の削除などの副作用になるべきでない。 能力~URLは、 資源に対する動作ではなく，当の資源~用の~access許可を符号化するべきである。 ◎ When capability URLs are used, they should be used within an appropriate HTTP verb to enable a relevant action. For example, an HTTP GET on a capability URL should not result in side effects such as the deletion of a resource. Capability URLs should encode access permissions for a resource, not actions on that resource.
注記： これらの~security保護策のいくつかは、 ~emailで送達される能力~URL用にはアリでないか不便である。 例えば，~email内の~URLは、 `GET$hm 要請でしか~accessし得ない。 これらの事例では、 代替な~security保護策のうち利用できるもの（短時間に失効させるなど）を利用することが推奨される。 ◎ Note Several of these security measures are not possible or inconvenient for capability URLs that are delivered by email. For example, URLs in email can only be accessed through a GET request. It's recommended that those alternative security measures (such as rapid expiry) that can be used are used in these cases.
失効した能力~URLに対しては、 ~serverは［ `410$st `Gone^ph ／ `404$st `Not Found^ph ］応答で応答するべきである。 実施においては、 これらの応答には小さな相違がある。 `410^st 応答を利用する場合、 ~appには［ 過去に どの能力~URLを~supportしていたか追跡し続ける ］ことも要求される — これは、 ~appの作業を~~増やすが，同じ能力~URLが新たな資源に再度アテガわれることも防止する。 ◎ When capability URLs expire, servers should respond to the URL with either a 410 Gone or a 404 Not Found response. In practice, there is little difference between these responses: a 410 Gone response requires the application to keep track of which capability URLs have been supported in the past; although this is more work for the application, it does prevent the reassignment of that capability URL to a new resource.
5.2. 能力~URLの設計
能力~URLは、 一意でなければならないが，推測するのも難しくなければならない。 例えば，能力~URLが https://example.org/access/{%number} の様な~~雛形~URLから生成されていて， %number が単に順に増えていく整数である場合、 アリな %number を順に走査して新たな情報を突止めるのは，至極~容易になろう。 ◎ Capability URLs must be unique, but they must also be hard to guess. For example, if capability URLs are generating using a URL like https://example.org/access/{number} and number is merely a sequentially increasing integer, it would be incredibly easy to scan through possible numbers to locate new information.
良な能力~URLを生成する手法の一つは、 ~secureな乱数~生成器を利用して作成された識別子を含めることである `RFC4086$r 。 乱数値の~entropy（情報量）が高いほど、 ~URLが正しく推測され得る確率は抑制される。 ~UUID~version 4 `UUID$r は、 120 ~bit以上あり，必要に足る~entropyがある — それ以前の~versionでは、 不足であるが。 同じ理由から、 ~entropyが高い乱数値は，~URLを実質的に一意にするに足るものになる — 2 個の乱数値が推測や偶然により一致する確率は、 ~entropyが高いときは，~~無視できる。 ◎ One method to generate a good capability URL is to include an identifier created using a secure random number generator [RFC4086]. A random value with sufficiently high entropy (120 bits or more) reduces the probability that the URL can be guessed correctly. A version 4 UUID [UUID] is sufficient, though other versions of UUID have insufficient entropy. For the same reason, a high entropy random value is sufficient to make a URL effectively unique. The probability that any two high entropy random values will be the same, either by guessing or accident, is negligible.
能力~URLを，容易に読み出せるよう［ 短くする／ヒトが読めるようにする／文字大小無視にする ］ことは、 委任が重要な~appにとって有利になり，誤記されにくくもなる。 しかしながら，能力~URLは、 ~URL短縮器には渡されるべきでない — 列挙【攻撃】に抗する保護が元の能力~URLより~~劣化するので。 ◎ There are advantages to making capability URLs short, human readable and case-insensitive, to make it easier for them to be read out, for applications in which delegation is important, and robust against mis-typing. However, capability URLs should not be passed through URL shorteners that have lower protections against enumeration than the original capability URL.
能力~URLを，~URLの素片~内に限り秘匿~keyを含むように設計すれば、 `Referer$h ~headerに結付けられて漏洩する可能性は避けられる。 これは、 `~web~key提案＠http://waterken.sourceforge.net/web-key/$にて推奨されている。 しかしながら，~pageの中に埋込まれた第三者-主体~scriptは、 素片も含む全部的な~URLへの~accessを有することに注意。 加えて，この設計は、 その素片~識別子を，~web~page用の通常の仕方では — すなわち，~pageの中の素片を識別するためには — 利用し得なくなることを意味する。 ◎ Designing capability URLs to include the secret key in a fragment rather than in the main URL avoids some of the leakage possibilities associated with the Referer header. This is recommended in the web-key proposal. Note however that third-party scripts embedded within pages do have access to full URLs, including the fragment. In addition, this design means that fragment identifiers cannot be used in the normal way for web pages, namely to identify a fragment within the page.
5.3. ~UI設計の考慮点
現時点では、 ~browserの~URL~barなど，組込みの~UI用に，~pageが通常の~URLでなく能力~URLを通して~accessされているかどうか検出する仕方は無い。 ◎ There is currently no way for built-in user interfaces, such as the location bar of a browser, to detect when a page is being accessed through a capability URL as opposed to a normal URL.
`replaceState()$c ~methodを利用すれば、 表示される~URLを正準的~URLに置換でき，能力~URLが~URL~bar内に可視になるのを防止する。 しかしながら，これは、 利用者が能力~URLを~bookmarkするのも防止する。 加えて，これを行う場合は、 ~pageが~unloadされるとき，能力~URLを履歴の中に戻すよう置換する必要もある — さもなければ，利用者は、 履歴を通して~pageへ戻るよう~navigateできなくなる。 ◎ To prevent the capability URL from being visible in the location bar, you can use the replaceState() method to replace the displayed URL with the canonical URL. However, this prevents the capability URL from being bookmarked by the user. In addition, if you do this, you should make sure the capability URL is replaced back into the history when the page is unloaded, otherwise it will not be possible for the user to navigate back to the page by navigating through their history.
他者と共有するためにある能力~URLを利用者に供する場合、 その~URLが広く共有された場合の帰結についても伝えるべきである。 ~pageは、 ~URLを取得した人々が，それで何を行えるか述べるべきである。 そこでは、 その~URLを安全に共有できる仕方を説明するべきである。 ◎ Users who are provided with capability URLs to share with others should be informed of the consequences of those URLs being shared widely. Pages should describe what people who get the URL can do with it, and explain the ways in which these URLs can be shared safely.
5.4. 正準的~URL
`§ 課題なり得るもの＠#disadvantages$にて要旨したとおり、 ~serverは、 資源への~accessを供するために利用される能力~URLが複数あるときには，その資源~用に単独の正準的~URLを有するべきである。 この~URLは、 正しい~access特権を有する（~accountを通して是認された）利用者から~access可能にし得る。 ◎ As outlined in § 4. Potential Issues, servers should have a single canonical URL for a resource when there are several capability URLs that are used to provide access to that resource. This URL may be accessible by users who have the correct access privileges (granted through an account).
正準的~URLは、 次に利用し得る： ◎ Canonical URLs may be used:
- 資源~用の能力~URLを~listして，それらの作成に対する制御を供する。 ◎ to list and provide control over the creation of capability URLs for the resource
- 資源が公になるとき，遷移される~URLとして。 ◎ as a URL that is transitioned to when a resource becomes public
- 誰もが制限付き特権で~accessできる公な~URLとして。 ◎ as a public URL that anyone can access with limited privileges
- 誰もが資源についての注釈に利用できる共通な~URLとして。 ◎ as a common URL that can be used by anyone in annotations about the resource
能力~URLを通して~accessされる~pageが内容を直に~serveする場合、
そのような~pageは，当の資源~用の正準的~URLへ~linkできる
— ~pageの~metadata（ `link$e 要素）において
`rel^a="`canonical$v"
を通して，あるいは資源の `Link$h ~headerの中に，同じ~parameterを与えることにより。
◎
If content is served directly from pages accessed through capability URLs, these pages can link to the canonical URL for the resource through rel="canonical" either in the metadata for the page (a <link> element) or within a Link header on the resource.
能力~URLが指す資源が後で公にされた場合、 `301$st `Moved Permanently^ph で応答して，［ 通常の公な正準的~URL ］への~redirectionを供するべきである。 ◎ If the capability URLs refer to a resource that is later made public, they should respond with a 301 Moved Permanently providing a redirection to the normal, public, canonical URL.
将来の作業
~TAGは，上の分析に従って、［ 特定0の~URLが能力~URLであることを指示する仕組み ］を追加することを究明することが有用になるであろうと考えている。 アリな手法として，次が挙げられる： ◎ Following the above analysis, the TAG thinks that it would be useful to investigate adding a mechanism to indicate that a particular URL is a capability URL. Possible methods for this include:
- `Content Security Policy＠~CSP3$ 指令 ◎ a Content Security Policy directive
- 要請に対する応答~内の~HTTP~header ◎ an HTTP header in responses to a request
- 能力~URLへの~linkに対する~link関係（特に，~email~messageの中で） ◎ a link relation on links to the capability URLs (particularly within email messages)
- ~URLの中の認識される文字列 ◎ a recognised string within URLs
~browserや~email~clientは、 次に挙げるような様々な仕方で~URLを保護することもできる： ◎ A browser or email client could then protect the URL in various ways such as:
- ~URL~barを隠蔽する ◎ obscuring the location bar
- `Referer$h ~headerに設定されないことを確保する ◎ ensuring that the Referer header was not set
- 第三者-主体~scriptから当の~page~URLへの~accessは許容しない ◎ disallowing access to the page URL from any third-party scripts
- 履歴の中にある それを隠す ◎ hiding it within the history
- ~accountが弱体化された疑いがある場合には、 ~accessを差止める ◎ sequestering access if there's suspicion that an account has been compromised
謝辞
この文書に対する変更を示唆された `Noah Mendelsohn^en 氏に特に謝意を。 ◎ Thanks in particular to Noah Mendelsohn for his suggested changes to this document.