capability-urls-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>Good Practices for Capability URLs （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="common-w3c.css" type="text/css">

<style>
.phrase {
	color: var(--dim-color);
}

figure > blockquote {
	margin: 0;
}

</style>

<script src="common0.js"></script>
<script src="common1.js" async></script>

<script>
Util.ready = function(){
	const source_data = {
		generate: expand,
	};
	Util.switchWordsInit(source_data);
}

function expand(){

	const class_map = this.class_map;
	const tag_map = this.tag_map;
	const link_map = this.link_map;

	return this.html.replace(
		/%[\w~一-鿆あ-ん]+|`(.+?)([$@\^])(\w*)/g,
		create_html
	);

	function create_html(match, key, indicator, klass){

if(!key) {//%
	return `<var>${match.slice(1)}</var>`;
}

let href = '';
let href1 = '';
{
	const n = key.indexOf('＠');
	if(n > 0) {
		href1 = key.slice(n + 1);
		key = key.slice(0, n);
	}
}
let text = key;

switch(klass){
case 'r':
	text = `[${key}]`;
	href = `#bib-${key.toLowerCase()}`;
	break;
case 'l':
	text = `"<code class="literal">${key}</code>"`;
	break;
case 'ph':
	text = `(${key})`;
	break;
case 'en':
	return `<span lang="en">${key}</span>`;
	break;
}

let tag = tag_map[klass];
if(tag) {
	let classname = class_map[klass];
	classname = classname ? ` class="${classname}"` : '';
	text = `<${tag}${classname}>${text}</${tag}>`;
}

if(indicator !== '^'){
	href = href1 || link_map[ klass ? `${klass}.${key}` : key ] || href;
	if(!href){
		console.log(match); // check error
		return match;
	}

	switch(indicator){
	case '$':
		text = `<a href="${href}">${text}</a>`;
		break;
	case '@':
		text = `<dfn id="${href.slice(1)}">${text}</dfn>`;
		break;
	}
}

return text;

	}
}

</script>

<script type="text/plain" id="_source_data">

●●options

spec_title:Good Practices for Capability URLs
spec_date:2018-10-30
trans_update:2020-02-01
source_checked:181030
page_state_key:WEBAPPSEC
original_url:https://w3ctag.github.io/capability-urls/
	https://www.w3.org/TR/capability-urls/
	abbr_url:CAPABILITY-URLS
spec_status:W3C TAG による知見
ref_id_prefix:bib-
ref_id_lowercase:true
copyright:2018,permissive
site_nav:tag-finding
trans_1st_pub:2020-02-01

●●original_id_map
normative:normative-references
informative:informative-references

●●class_map
h:header
st:status
hm:method
ph:phrase
a:attr
e:element
v:value

●●tag_map
I:code
m:code
c:code
e:code
a:code
h:code
v:code
st:code
hm:code
ph:span
b:b
i:i
s:samp

●●link_map

h.Referer:~HTTPsem#field.referer
h.Link:~HTTPweblink#field.link
h.Referrer-Policy:~REFERRER-POLICY#referrer-policy-header-dfn

hm.GET:~HTTPsem#GET

st.410:~HTTPsem#status.410
st.404:~HTTPsem#status.404
st.301:~HTTPsem#status.301

e.link:~HEmetadata#the-link-element
e.meta:~HEmetadata#the-meta-element
a.name:~HEmetadata#attr-meta-name
a.content:~HEmetadata#attr-meta-content

v.referrer:~HEmetadata#meta-referrer
v.noreferrer:~HTMLlinks#link-type-noreferrer
v.canonical:~HTMLlinks#link-type-canonical

v.origin-when-cross-origin:~REFERRER-POLICY#referrer-policy-origin-when-cross-origin
v.origin:~REFERRER-POLICY#referrer-policy-origin
v.no-referrer:~REFERRER-POLICY#referrer-policy-no-referrer

c.replaceState():~WINDOW#dom-history-replacestate

能力~URL:#dfn-capability-urls

●●words_table1

●●words_table

	●能力 URL
失効-:expire::~
	短時間に失効させる:rapid expiry
	失効-:Expire
新鮮:fresh:~
廃止:revocation::~
廃止-:revoke::~
交換:exchange:~
所持-:possess:~
渡す:passする:~
渡され:passされ:~
渡して:passして:~
忘れた:forgetした:~
忘れる:forgetする:~
	忘れたとき:forgotten
思出せ:rememberでき:思い出せ
思出して:rememberして:忘れずにいて
promptする::促す
共有:sharing::~
私的:private::~::プライベート
私用:private::~::プライベート
匿名で:anonymousに:~
人々:people:~
各個人:individual:~
個人-:personal:~
個人:person:~
	他者:others
	誰にとっても:for everyone
	誰もが／誰にでも／誰でも／誰からも／誰であれ:anyone
	誰であれ:whichever
	誰か:someone
	設定し直す:reset
撤回:withdrawal:~
法的:legal:~

	●能力 URL（例
Doodle:
Flickr:
GitHub:
	GitHub:Github
Google-Calendar:Google Calendar
Second-Life:Second Life
Twitter:
Dropbox:
Gist:
REST:
Guest-Pass:
	~Guest-Pass:Guess-Pass
iCalendar:
Linden-Lab:Linden Lab
Tahoe-LAFS:
	~Tahoe-LAFS:Tahoe
bookmark::::ブックマーク
calendar::::カレンダー
email::::メール
feed-reader:feed reader:::フィードリーダ
help::::ヘルプ
gist:
出席-:attend:~
常連:regular::~
	常連:more regular
	正規
directory::::ディレクトリ
UUID:
long-polling:
pipeline::::パイプライン
	~pipeline化:pipelined
友人:friend:~
poll:
組織:organisation:~
協同者:collaborator:~
協同-:collaborate:~
協同:collaboration:~
同僚:colleagues:~
招待-:invite:~
代表者:representative:~
会合:meeting:~
手配-:arrange:~
direct::::ダイレクト
	direct message
公式-:official:~
	公式-:Official
近過去:recent:~

	一週間:a week
	肩越し:over shoulder
	手はずを整える:arrange
	~~参加する:take part
	参加:Participation:
	あなたの:Your／:your
	履歴:History
	私用:Private
	登録:Reg
	登録:Registration
	~address:Address
	^en:Grab
	~help:Help
	管理用:Administration
	~codeに直書き:hard-code
	読み取りに限る／読み取りのみ:read-only
	読まれ:read
	読める:readable
	読み書き:read-write
	読み出す:read out
	検証y-のみ:verify-only
	~web~key:web-key

	●network
送信器:sender::~
受信器:receiver::~
URI:
ISP:
transaction::::トランザクション
unload::::アンロード
POP3:
流す:flowする:~
crawler:
通過点:points in transit:~
多重化:multiplexing::~

	●保安
password::::パスワード
username::::ユーザ名
account::::アカウント
login::::ログイン
log-in:log in:::ログイン
phishing::::フィッシング
CSRF:cross-site request forgery:CSRF
sniff:
帯域幅:bandwidth::~
特権:privilege::~
権:right::~
	~access権:right
暗号化-:encrypt::~
認証:authentication::~
認証-:authenticate::~
秘匿:secret::~
察知-:learn:~
推測-:guess:~
推測:gussing:~
	推測-不能:unguessable
	推測-可能:guessable
平文:plain::~
	~secureでなく~insecure:
弱体化-:compromise::~
弱体化:compromises::~
短縮化:shortening::~
短縮器:shortener::~
	漏洩-:leak out
	漏洩-:leakage
中央-:central:~
制限付き:limited:~
疑い:suspicion:~
route::::ルート
対抗策:countermeasures::~
保護策:measures::~
安全策:safeguards::~
	暗号化されない:unencrypted
走査-:scan:~
乱数:random number::~
乱数値:random value::乱数
entropy::::エントロピー
確率:probability::~
制限時間:timeout::~
時間枠:timeout window:~
頻度:rate:~
管理者:administrator:~
突止める:locateする:突き止める
差止める:sequesterする:差し止める
隠蔽-:obscure:~
価値:value:~
	高~価値:high-value
	信用されない:untrusted
	~secureでな:insecure
	抗して:against
	誰かの手中:into hands
	講じておく:put in place
	~access不能:inaccessible
	能力:Capability

	●仕様
TAG:
	web-based:web
agent::::エージェント
警告-:warn:~
重荷:burdensome:~
負担:burden:~
選ぶ:chooseする:~
隠され:hideされ:~
隠す:hideする:~
集める:gatherする:~
手助け:facilitate:~
有利:advantage:~
不利:disadvantage:~
機能-:function:~
分野:areas:~
対処法:workaround:~
微妙:subtle:~
発生-:arise:~
傾向:tend:~
今日:today:~
究明-:investigate:~
分析-:analyze:~
分析:analysis:~
準拠性:compliance:~
必要十分:adequate:~
不便:inconvenient:~
有益:beneficial:~
提起-:raise:~
稼働時:run-time:~
自己完結的:self-contained:~
注力-:focus:~
破壊的:destructive:~
比較的:relativeに:~
rationale::背後にある理由
頻繁:frequent:~
	頻繁にある:frequently
	頻繁に:very frequently
助言:advice:~
可能性:possibility:~
難題:challenge:~
強調-:highlight:~
偶然:accident:~
駆立てる:motivateする:駆り立てる
	駆立てるに足る:sufficient 〜 ~motivated
助け:help:~
	助けになる:help
生きた:living:~
指向-:orient:~
良な:good:良い
	方が良い:better
	もっと良い:or better yet
難しく:hardで:~

	最小~化:minimise
	広く:widely
	広範に:widespread
	広く用いられているもの:broad
	急増している:proliferation
	極めて:extremely
	わけにはいかない:cannot
	し続ける:continue
	その場で:on demand
	伝える:tell
	保つ／保ちながら／保って／し続ける:keep
	保てる／保たれ:kept
	元々:originally
	十分:enough
	単に:merely
	好ましい:preferable
	対象に:target
	小さな:little
	小さな:small
	最終的には:eventually
	望む:wishする
	期待されない:unexpected
	許容しない:disallow
	逆に:conversely
	相応に:fairly
	~~現場:where
	主な／主:main
	事:fact
	何か言う:talk
	何もない:nothing
	短く言えば:in short
	の一節:reading
	に関する:regarding
	に反する:runs contrary
	求まれない:unwanted
	なり得るもの:potential
	あり得る:potentially
	〜しないよう:against
	~~統一のとれた:coherent
	紛れもなく:arguably
	伝える:inform
	それ以降は〜ない doesn't 〜 ongoing
	〜でなく:as opposed to
	至極:incredibly
	導く:lead
	適度に:reasonably
	課す:impose
	入手:get hold of
	授けら:confer
	遂には:eventually
	ようにも見える:appears
	天秤にかける:weigh up
	誤記されにくい:robust against mis-typing
	すなわち:namely
	~~実際に:indeed
	誤って:mistakenly
	事:fact
	一種:type
	さほど容易でない:less easy
	できなくなる:will not be possible
	~~理由:because
	初めて:the first place
	対象を絞る／対象に限る:targeted
	これまでの:previous
	滅多にない:seldom
	うっかり:accidentally
	~~無視できる:negligible
	気付く:become aware of
	明らかにされ:evident
	もたらし:open up
	かなり:quite
	兼ねている:provide
	手軽な:low friction
	行える:able to do
	~~理由:because
	必要もある:you should make sure
	必要に足る／足る:sufficient
	不足:insufficient
	必要に足るまで:sufficiently
	必要yなもの:necessity
	必要をなくし:remove the necessity
	~~説明:illustrate
	するべく:seeking
	ほぼ~~等しく:much-like
	文言を添えて:saying
	-:potential 〜
	考えて:think
	さらには:moreover
	知る:know

	●未分類
overhead::::オーバーヘッド
stateless::::ステートレス
toolbar::::ツールバー
pop-up::::ポップアップ
閉じる:closeする:~
編集-:edit:~
過去:past:~
backup::::バックアップ
閲覧v:view::閲覧
open-cloud:open cloud
main::::メイン
為され:makeされ:~
現れる:appearする:~
追った:followした:~
力:power:~
コピペ:copy:~

	再度アテガわれる:reassignment
	組み込む:plug in
	~~費やす:takes up
	上位にある~path:path under which 〜 are found
	属する:reside
	属する:belong
	短く:short
	より~~劣化する:lower
	戻すよう／戻るよう:back
	設定し直す:Reset
	方へ:around
	以降で:the rest of
	順に増えていく:sequentially increasing
	~method:verb
	~version付き:versioned
	含む:includeする
	図:figire
	ごとに:per-
	~UI:user interface
	高い:high
	になる:become
	分:minute
	場所／-:in place
	指す:refer
	通じる:through
	can be:can me
	べき:should
	謝意:Thanks

	●指示語
	以降は:no longer
	3 種:three
	しばらくの間:for a while
	とても高い:very high
	より大きな:larger
	一定の:certain
	他所:elsewhere
	複数:several
	一部分:portion:~
	部位:portion:~
	一連の:set of
	後者:second

●●images
＠capability-urls/
gcal｜｜｜.webp
gist｜｜｜.webp
doodle｜｜｜.webp
flickr-guest-pass｜｜｜.webp
flickr-guest-pass-history｜｜｜.webp

●●ref_normative

[RFC4086]
    Randomness Requirements for Security. D. Eastlake 3rd; J. Schiller; S. Crocker. IETF. June 2005. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc4086

●●ref_informative

[UUID]
    Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 object identifier components. ITU-T. ITU-T Rec. X.667. URL: https://www.itu.int/ITU-T/studygroups/com17/oid/X.667-E.pdf


●●trans_metadata
<p>
~THIS_PAGEは、~W3Cにより
<a href="https://www.w3.org/2001/tag/findings">TAG Finding</a>
として公開された
<a href="~SPEC_URL">Good Practices for Capability URLs</a>
を日本語に翻訳したものです。
~PUB
</p>

●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/capability-urls/
編集
	Jeni Tennison (<a href="https://www.theodi.org/">ODI</a>)
リポジトリ
	<a href="https://github.com/w3ctag/capability-urls">We are on Github.</a>
	<a href="https://github.com/w3ctag/capability-urls/issues">File a bug.</a>
	<a href="https://github.com/w3ctag/capability-urls/commits/gh-pages">Commit history.</a>
</script>

</head>

<body>

<header>
	<hgroup>
<h1>能力 URL 用の良い実施 — Good Practices for Capability URLs</h1>

	</hgroup>
</header>

<div id="MAIN" hidden>

	<section id="abstract">
◎要約

<p>
`能力~URL$は、
それを有する誰にでも，それが指す資源への~accessを是認する。
~appの設計~patternには、
これが特に有用になるものがある
— 能力~URLは、
利用者が~siteに~log-inする必要をなくし，他者に容易に委任できるので。
が、
それらの利用は，~securityに何らかの課題をもたらし得る
— ~URLは、
一般に，秘匿に保つことは要求されないことから、
能力~URLが意図されない誰かの手中へ漏洩し得る~routeには，様々なものがあるので。
この文書は、
能力~URLを自身の~appの中に組入れたいと望む~web開発者~向けに，
これらの~riskを最小~化するための良な実施をいくつか供する。
◎
Capability URLs grant access to a resource to anyone who has the URL. There are particular application design patterns for which this is useful as they remove the necessity for users to log in to a site and are easily delegated to others. But their use can open up some security issues. URLs are not generally required to be kept secret, and there are various routes through which capability URLs can leak into unintended hands. This document provides some good practices for web developers who wish to incorporate capability URLs into their applications, to minimise these risks.
</p>

	</section>
	<section id="sotd">
◎位置付け

<p>
この節では、
公表~時点における…
【以下，この節の他の内容は、~SOTD-W3Cに移譲。】
</p>

<p>
これは、
`TAG Finding＠https://www.w3.org/2001/tag/findings$
【 `技術-~architecture~group^i による知見】
として公表された，生きた文書である。
この文書が含むのは、
開発者~向けの助言のみであり，規範的な内容は包含しない（例：実装の準拠性についてなど）。
◎
This is a living document published as a TAG Finding. It does not contain any normative content (eg about implementation compliance), only advice for developers.
</p>

	</section>
<main id="MAIN0">
	<section id="intro">
<h2 title="Introduction">1. 序論</h2>

<p>
~webに公表された情報への~accessを制御するために広く用いられている手法には、
次の 2 つがある：
◎
There are two broad methods of controlling access to information that is published on the web:
</p>

<ol>
	<li>
~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
</li>
	<li>
情報は［
隠蔽された／推測-不能な
］~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
</li>
</ol>

<p>
後者の手法に利用される~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.
</p>

<p>
~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.
</p>

<p>
この文書は、
次について述べる：
◎
This document describes:
</p>
<ul>
	<li>
能力~URLが今日の~webの~~現場で利用されている例
◎
examples where capability URLs are used on the web today
</li>
	<li>
内容への~accessを制御するために能力~URLを利用する際の，有利と不利
◎
advantages and disadvantages of using capability URLs to control access to content
</li>
	<li>
能力~URLを利用する~web~siteを作成する際の，設計の考慮点
◎
design considerations when creating websites that use capability URLs
</li>
	<li>
能力~URLの利用を~supportする技術-開発の分野
◎
areas of technical development to support the use of capability URLs
</li>
	<li>
~URLを秘匿に保つことに関係する課題
◎
Issues relating to keeping URLs secret
</li>
</ul>

	</section>
	<section id="examples">
<h2 title="Example Capability URLs">2. 能力~URLの例</h2>

<p>
能力~URLは、
広範に利用されている。
この節では、
能力~URLが~webで利用されている~~現場からの例を包含する。
◎
Capability URLs are in widespread use. This section contains examples from the web where capability URLs are used.
</p>

		<section id="password-resets">
<h3 title="Password Resets">2.1. ~passwordを設定し直す</h3>

<p>
利用者が~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.
</p>

<p>
代わりに，利用者に~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.＼
</p>

<div class="example">

<p>
次の例は、
~Dropboxから：
◎
This example is from Dropbox:
◎
Example 1
</p>

<blockquote>
<p lang="en">
Your Dropbox password recently expired.
You can reset it `here＠https://www.dropbox.com/l/Q8eJH22ft0ckDJDeff1Do10/password_reset$.
</p>
<p>
（あなたの~Dropbox~passwordは近過去に失効しました。 `ここ^i で設定し直すことができます。）
</p>

</blockquote>

<p>
この事例では、
能力~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.
</p>

</div>

		</section>
		<section id="second-life">
<h3 title="Second Life">2.2. ~Second-Life</h3>

<figure id="fig-using-capability-urls-linden-lab-official-registration-api">
<blockquote>
<p lang="en">
Reg API capabilities represent permissions to perform certain actions.
</p>
<p>
（登録~API能力は、
一定の動作を遂行する許可を表現します。）
</p>
</blockquote>
<figcaption>
図 1.
`能力~URLの利用-法＠http://wiki.secondlife.com/wiki/Linden_Lab_Official:Registration_API#Using_capability_URLs$
— ~Linden-Lab公式-：登録~API
◎
Figure 1 Using capability URLs – Linden Lab Official:Registration API
</figcaption></figure>

<p>
~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:
</p>

<div class="example">
<p>
◎
Example 2
</p>

<pre class="lang-xml">
&lt;llsd&gt;
  &lt;map&gt;
    &lt;key&gt;create_user&lt;/key&gt;
    &lt;string&gt;https://cap.secondlife.com/cap/0/35ff3b8c-a30d-4d18-b29a-e3f7f6c79cb6&lt;/string&gt;
 
    &lt;key&gt;check_name&lt;/key&gt;
    &lt;string&gt;https://cap.secondlife.com/cap/0/6e528ba1-a8b0-4f6b-8b56-362ee6f5cef8&lt;/string&gt;
 
    &lt;key&gt;get_last_names&lt;/key&gt;
    &lt;string&gt;https://cap.secondlife.com/cap/0/be4e4d2e-c00a-46cd-bb8d-d17cb8e92c9b&lt;/string&gt;
 
    &lt;key&gt;get_error_codes&lt;/key&gt;
    &lt;string&gt;https://cap.secondlife.com/cap/0/e75f81a5-b7da-4480-8f95-b1cf9d2d680f&lt;/string&gt;
  &lt;/map&gt;
&lt;/llsd&gt;
</pre>
</div>

<p>
文書化は、
これらの能力~URLを利用するための指針として，次の 2 つを供する：
◎
The documentation provides two guidelines for using these capability URLs:
</p>

<figure id="fig-using-capability-urls-linden-lab-official-registration-api-1">
<blockquote cite="http://wiki.secondlife.com/wiki/Linden_Lab_Official:Registration_API#Using_capability_URLs">

<ul>
	<li>
<p lang="en">
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.
</p>

<p>（
能力~URLは、
~codeに直書きしないでください。
能力~URLは、
【それを代理する】定数として~code化するか，稼働時に得る方がさらに良いです。
能力~URLは、
最終的には失効することになるので，新鮮な方が常に良いです。
）</p>
	</li>
	<li>
<p lang="en">
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.
</p>

<p>（
能力~URLは、
秘匿に保ってください。
あなたに是認される能力は、
あなた用に限られるものと意味されています。
能力~URLは、
~passwordにほぼ~~等しく敏感です。
さらには、
~Linden-Labは各~能力の利用を追跡します。
）</p>

	</li>
</ul>

</blockquote>
<figcaption>
図 2.
`能力~URLの利用-法＠http://wiki.secondlife.com/wiki/Linden_Lab_Official:Registration_API#Using_capability_URLs$
– ~Linden-Lab公式-：登録~API
◎
Figure 2 Using capability URLs – Linden Lab Official:Registration API
</figcaption>
</figure>

		</section>
		<section id="google-calendar">
<h3 title="Google Calendar">2.3. ~Google-Calendar</h3>


<div class="p">
<p>
~Google-Calendarは、
~calendarの［
~XML／~iCalendar
］形式~用に私用~address（ `Private Address^en ）を供する。
これらは、［
~feed-reader／~calendar~program
］の中で ~calendarへの~accessを供するためとして，誰でも利用できるが、
利用者には警告される：
</p>

<blockquote>
<p lang="en">
"Your calendar's Private Address was designed for your use only, so be sure not to share this address with others."
</p>
<p>
（あなたの~calendarの私用~addressは，あなたの利用~用に限り設計されたものです。
この~addressを他者と共有しないでください。）
</p>
</blockquote>

<p>
（ `“私用~address” について＠https://support.google.com/calendar/answer/37106?hl=en&amp;ref_topic=1672529$
から~~引用）
</p>

◎
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').
</div>

<p>
私用~addressに結付けられた~helpは、
同様に，~URLを他者と共有しないよう警告する：
◎
The help associated with Private Addresses similarly warns against sharing the URLs with others:
</p>


<figure id="fig-help-associated-with-private-address-in-google-calendar">
<p class="alt" id="_dgm-gcal">
~help~boxの一節：
<q>
あなたの~calendarの私用~addressは、
あなたの利用~用に限り設計されています。
あなたの~calendarを成すすべての情報は、
あなたの私用~linkを介して可用になるので、
この~addressを他者と共有しないでください。
私用~addressを変更して，これまでの~accessを不能化したい場合は、
“私用~URLを設定し直す（ `Reset Private URLs^en ）”
~linkを~clickしてください。
</q>
◎
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.'
</p>

<figcaption>
図 3.
~Google-Calendar内の私用~addressに結付けられた~help
◎
Figure 3 Help associated with Private Address in Google Calendar
</figcaption></figure>

		</section>
		<section id="github-gists">
<h3 title="Github Gists">2.4. ~GitHub~Gist</h3>

<p>
~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.
</p>

<figure id="fig-a-secret-github-gist">
<p class="alt" id="_dgm-gist">
~Gist~pageは~pop-upで次を説明している：
<q>
秘匿な~gistは、
探索~engineからは隠されますが，あなたが~URLを与えた誰からも可視になります。
</q>
◎
Gist page with a pop-up explaining 'Secret gists are hidden from search engines but visible to anyone you give the URL.'
</p>

<figcaption>
図 4.
秘匿な~GitHub~Gist
◎
Figure 4 A secret GitHub Gist
</figcaption></figure>

		</section>
		<section id="doodle-polls">
<h3 title="Doodle polls">2.5. ~Doodle~poll</h3>

<p>
~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:
</p>

<figure id="fig-doodle-page-for-a-new-poll">
<div class="alt" id="_dgm-doodle">
<p>
~Doodle~pageは、
次の~URLを供している：
</p>

<ul>
	<li>
参加~link（ `Participation link^en ）には、
次の文言を添えている
⇒
<q>
招待したい人に この~linkを送信してください。
</q>
</li>
	<li>
管理用~link （  `Administration link^en ）には、
次の文言を添えている
⇒
<q>
この~pollを［
変更する／閉じる／削除する
］ときは、
この~linkに~accessしてください。
</q>
</li>
</ul>

◎
Doodle page providing URLs with a Participation link saying 'Send this link to anyone you wish to invite.' and an Administration link saying 'Access this link to change, close or delete this poll.'
</div>

<figcaption>
図 5.
新たな~poll用の~Doodle~page
◎
Figure 5 Doodle page for a new poll
</figcaption></figure>

		</section>
		<section id="flickr-images">
<h3 title="Flickr images">2.6. ~Flickr画像</h3>

<p>
~Flickr上の私的な画像は、
~Guest-Passを通して共有できる
— それは、
所与の画像~用に その場で生成される。
◎
Private images on Flickr can be shared through Guest Passes which are generated for a given image on demand.
</p>

<figure id="fig-flickr-dialog-for-a-new-guest-pass">
<p class="alt" id="_dgm-flickr-guest-pass">
~Flickr~dialogでは、
~Guest-Pass用に
<q>~linkをつかむ（ `Grab the link^en ）</q>
文言を添えて，利用者を~Guest-Pass履歴に訪問するよう招待する。
◎
Flickr dialog saying 'Grab the link' for a Guest Pass and inviting the user to visit the Guess Pass History.
</p>

<figcaption>
図 6.
新たな~Guest-Pass用の~Flickr~dialog
◎
Figure 6 Flickr dialog for a new Guest Pass
</figcaption></figure>

<p>
利用者は、
~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.
</p>

<figure id="fig-flickr-guest-pass-history">
<p class="alt" id="_dgm-flickr-guest-pass-history">
~Flickr上の~Guest-Pass履歴の一部分。
~Guest-Passを失効させる~optionを示している。
◎
Portion of a Guest Pass History on Flickr, showing the option to Expire the Guest Pass.
</p>

<figcaption>
図 7.
~Flickrの~Guest-Pass履歴
◎
Figure 7 Flickr Guest Pass History
</figcaption></figure>

		</section>
		<section id="tahoe-lafs">
<h3 title="Tahoe-LAFS">2.7. ~Tahoe-LAFS</h3>

<p>
~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:
</p>

<pre>
https://zooko.com/uri/URI:DIR2-MDMF-RO:dwvqalbdt4ax4vgupcewxljg3u:bej7hhojmpuugy77oyydmazf6uu7huiipkctih7adky7e6txavnq/klog.html
</pre>

<p>
`~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.
</p>

		</section>
	</section>
	<section id="advantages">
<h2 title="Reasons to Use Capability URLs">3. 能力~URLを利用する理由</h2>

<p>
上に述べた例から明らかにされた，能力~URLを利用する~rationaleには、
以下の各~下位節に挙げる 4 つがある。
◎
There are four rationales for using capability URLs evident in the examples described above.
</p>

		<section id="no-login-required">
<h3 title="No Login Required">3.1. ~loginは要求されない</h3>

<p>
能力~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:
</p>
<ul>
	<li>
利用者が~loginの詳細を思出せないとき
◎
users who can't remember login details
</li>
	<li>
利用者が~accountを作成したいと求めないとき
◎
users who don't want to create accounts
</li>
	<li>
開発者が~accountを~supportしたいと求めないとき
◎
developers who don't want to support accounts
</li>
</ul>

			<section id="forgotten-passwords">
<h4 title="Forgotten Passwords">3.1.1. ~passwordを忘れたとき</h4>

<p>
利用者が~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:
</p>

<ul>
	<li>
~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
</li>
	<li>
能力~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
</li>
	<li>
能力~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
</li>
</ul>

			</section>
			<section id="low-friction-accounts">
<h4 title="Low Friction Accounts">3.1.2. 手軽な~account</h4>

<p>
利用者が自身の~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.
</p>

<p>
~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.
</p>

<p>
能力~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).
</p>

<p>
能力~URLのうち［
~accountを要求することなく，協同を手助けする
］ために利用されるものは、
一般に 常連~利用者により制御される
— その者は，次を望むこともあろう：
◎
Capability URLs that are used to facilitate collaboration without requiring accounts are generally controlled by a regular user, who might wish to:
</p>
<ul>
	<li>
協同したいと望む［
人々／~group
］ごとに，異なる能力~URLを作成する。
◎
create different capability URLs for different people or groups that they wish to collaborate with
</li>
	<li>
資源に許可したいと望む動作の種別ごとに（例：
編集-用／~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)
</li>
	<li>
意図された~groupの外側で共有されたものと察知した場合に備えて、
当の能力~URL用の許可を廃止-可能にする。
◎
be able to revoke permissions for given capability URLs if they learn they have been shared outside the intended group
</li>
</ul>

			</section>
			<section id="websites-without-accounts">
<h4 title="Websites without Accounts">3.1.3. ~accountを伴わない~web~site</h4>

<p>
~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.
</p>

<p>
~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.
</p>

<p>
これらの事例では、
~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.
</p>

			</section>
		</section>
		<section id="managing-access-on-sandboxed-domains">
<h3 title="Managing Access on Sandboxed Domains">3.2. ~sandbox化された~domainに対する~accessの管理-法</h3>

<p>
信用されない利用者からの内容を~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.
</p>

<p>
しかしながら，これらの事例では、［
利用者に特有な~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.
</p>

		</section>
		<section id="easy-delegation">
<h3 title="Easy Delegation">3.3. 容易な委任</h3>

<p>
能力~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.
</p>

<p>
例えば，組織どうしの会合を手配しようと試行している ある利用者は、［
会合に出席するべき他の組織の人々
］全員は知らないかもしれない。
通常の~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.
</p>

<p>
したがって，能力~URLは、
~accountに基づく~systemが行えるより容易に，~networkを通して許可を流すことを可能化できる。
◎
Capability URLs can thus enable permissions to flow through networks more easily than they can with an account-based system.
</p>

		</section>
		<section id="easy-client-api">
<h3 title="Easy Client API">3.4. 容易な~client~API</h3>

<p>
~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.
</p>

<p>
そのような場合、
能力~URLを利用できる。
~clientは：
◎
Capability URLs can be used instead. Clients:
</p>
<ol>
	<li>
認証を通常通り遂行して，
◎
perform authentication as normal
</li>
	<li>
当の~session用に以降で利用する能力~URLの~listを要請して，
◎
request a list of capability URLs to use for the rest of the session
</li>
	<li>
それらの~URLを，認証を伴わずに利用する。
◎
use those URLs without authentication
</li>
</ol>

<p>
これは、
交換を相応に~secureに保ちながら，各~transactionから認証~costを除去する。
◎
This removes the authentication cost on each transaction while keeping the exchanges fairly secure.
</p>

<p class="note">注記：
ここには、［
頻繁に行き交う小さな~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.
</p>

		</section>
	</section>
	<section id="disadvantages">
<h2 title="Potential Issues">4. 課題になり得るもの</h2>

<p>
~URLは、
元々，秘匿~情報を包含するように設計されてはいない。
能力~URLを利用することには、
その事から発生している不利がある。
◎
There are disadvantages to using capability URLs arising from the fact that the URLs were not originally designed to contain secret information.
</p>

		<section id="risk-of-exposure">
<h3 title="Risk of Exposure">4.1. 公開の~risk</h3>

			<section id="exposure-risk-analysis">
<h4 title="Exposure Risk Analysis">4.1.1. 公開~riskの分析</h4>

<p>
一般に，~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.
</p>

<p>
もっと微妙な公開~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.
</p>

<p>
利用者が能力~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.
</p>

<p>
~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).
</p>

<p>
いくつかの~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.
</p>

<p>
これらの~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.
</p>

<p>
短く言えば、
能力~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.
</p>

			</section>
			<section id="exposure-risk-scenarios">
<h4 title="Exposure Risk Scenarios">4.1.2. 公開の~riskがある局面</h4>

<p>
能力~URLの共通的な利用において発生する問題のいくつかを，以下に挙げる例で~~説明する。
◎
The following examples illustrate some problems that arise in common uses of Capability URLs.
</p>

<div class="example">
<p>
能力~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.
</p>
</div>

<p>
実施においては、
~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.
</p>

<div class="example">
<p>
~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.
</p>
</div>

<p>
この時間枠は、
多くの局面で，~~実際に受容-可能な~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.
</p>


<p>
能力~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.
</p>

			</section>
		</section>
		<section id="handling-compromises">
<h3 title="Handling Compromises">4.2. 弱体化の取扱い</h3>

<p>
能力~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.
</p>

<p>
能力~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. 
</p>

		</section>
		<section id="web-architecture">
<h3 title="Web Architecture">4.3. ~web~architecture</h3>

<p>
能力~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.
</p>


<div class="p">

<p>
同じ資源~用に複数の~URLを利用することは、
良な実施
（ `Architecture of the World Wide Web, Volume One＠~TR/webarch/#avoid-uri-aliases$【！ ~web~architecture 第 1 巻】）
に反するようにも見える：
</p>

<blockquote id="fig-architecture-of-the-world-wide-web-volume-one">
<strong>
良な実施：別名~URIは避けること。
</strong>
~URI所有者は、
同じ資源に任意に異なる~URIを結付ける`べきでない^em。
</blockquote>

◎
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
</div>

<p>
しかしながら，この推奨の~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.
</p>


<p>
しかしながら，［
資源への~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. 
</p>

		</section>
		<section id="beyond-the-single-page">
<h3 title="Beyond the Single Page">4.4. 単独の~pageを超える</h3>

<p>
`§ 能力~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.
</p>

<div class="example">

<p>
~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:
</p>

<pre>
http://example.org/${DIR-CAPABILITY}/path/to/resource
</pre>

<p>
これは、
その~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.
</p>
</div>

		</section>
	</section>
	<section id="recommendations">
<h2 title="Recommendations">5. 推奨</h2>

<p>
この節では、
能力~URLを~web~appの中で いつ, どう利用するかについて，推奨を要旨する。
◎
This section outlines recommendations about when and how to use capability URLs within web applications.
</p>

		<section id="application-design">
<h3 title="Application Design">5.1. ~appの設計</h3>

<p>
`§ 能力~URLを利用する理由＠#advantages$では、
能力~URLが有用になる 3 種の状況を要旨した：
◎
In § 3. Reasons to Use Capability URLs we outlined three situations in which capability URLs are useful:
</p>

<ul>
	<li>
ある動作を遂行するために，利用者が~log-inする必要を避ける。
◎
To avoid the need for users to log in to perform an action.
</li>
	<li>
~URLを他者と共有するのを容易にする。
◎
To make it easy for those with whom you share URLs to share them with others.
</li>
	<li>
~APIにおける認証~overheadを避ける。
◎
To avoid authentication overheads in APIs.
</li>
</ul>

<p>
能力~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:
</p>

<ul>
	<li>
代わりに，~accountに基づく仕組みを利用する~accessに制約することもできるか？
◎
Could access be restricted using an account-based mechanism instead?
</li>
	<li>
~HTTP以外の~protocolを利用するべきか？
◎
Should you use a protocol other than HTTP?
</li>
</ul>

<p>
`§ 公開の~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:
</p>

<ul>
	<li>
<strong>
能力~URLは、
`https://^c ~URLにするべきである。
</strong>
これは、
~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.
</li>
	<li>
<strong>
能力~URLを利用者に伝える~pageは、
~HTTPSを通して~serveすることにより，暗号化されるべきである。
</strong>
これもまた、
平文~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.
</li>
	<li>
<strong>
能力~URLは、
失効するべきである。
</strong>
例えば，［
能力~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.
</li>
	<li>
<p>
<strong>
能力~URLを通して~accessされる~pageは、
第三者-主体~web~siteへの~linkを含むべきでない
</strong>
— 当の能力~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:
</p>
		<ul>
			<li>
そのような~linkには、
<code>`rel^a="`noreferrer$v"</code>
を利用する。
◎
using rel="noreferrer" on the links
</li>
			<li>
当の~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
</li>
			<li>
~HTML~pageの中で
<code>&lt;`meta$e `name$a="`referrer$v" `content$a="..."&gt;</code>
を利用して，
`content^a 属性の値に前項に挙げた値を利用する。
【！原文誤： `value^v → `content^a 】
◎
using a &lt;meta name="referrer" value="origin"&gt; header within the HTML page; again none or origin-when-cross-origin could be used instead of origin
</li>
		</ul>

<p class="trans-note">【
すなわち， `Referer$h ~header自体の送信を防止するか，その値が秘匿~keyを含まなくなるようにする。
】【
上の~listにおける原文の記述は、
~~正確でない（過去の仕様に基づく？）ので，この訳では修正を加えている。
】</p>

	</li>
	<li>
<strong>
能力~URLを通して~accessされる~pageは、
信用されない第三者-主体~scriptを含むべきでない
</strong>
— ~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.
</li>
	<li>
能力~URLが認証-済み利用者により制御される場合、
<strong>
［
その利用者が、
自身が制御する資源に結付けられた能力~URLを廃止する
］ことがアリにされるべきである
</strong>
。
そのような利用者は、
そのような複数個の能力~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.
</li>
	<li>
<strong>
能力~URLの秘匿~keyを成す部分より上位にある~pathは、
`robots.txt^c の中に~listされるべきである
</strong>
— `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.
</li>
	<li>
<strong>
能力~URLが属する~URL空間への~accessは、
頻度を制限するべきである。
</strong>
これは、
アリな~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.
</li>
</ul>

<p>
<strong>
能力~URLを利用して関連な動作を可能化するときは、
適切な~HTTP ~methodの中で利用するべきである。
</strong>
例えば，能力~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.
</p>

<p class="note">注記：
これらの~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.
</p>

<p>
<strong>
失効した能力~URLに対しては、
~serverは［
`410$st `Gone^ph ／ `404$st `Not Found^ph
］応答で応答するべきである。
</strong>
実施においては、
これらの応答には小さな相違がある。
`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.
</p>

		</section>
		<section id="capability-url-design">
<h3 title="Capability URL Design">5.2. 能力~URLの設計</h3>

<p>
<strong>
能力~URLは、
一意でなければならないが，推測するのも難しくなければならない。
</strong>
例えば，能力~URLが
<samp>https://example.org/access/{%number}</samp>
の様な~~雛形~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.
</p>

<p>
良な能力~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.
</p>

<p>
能力~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.
</p>

<p>
能力~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.
</p>

		</section>
		<section id="ui-design-considerations">
<h3 title="UI Design Considerations">5.3. ~UI設計の考慮点</h3>

<p>
現時点では、
~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.
</p>

<p>
`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.
</p>

<p>

<strong>
他者と共有するためにある能力~URLを利用者に供する場合、
その~URLが広く共有された場合の帰結についても伝えるべきである。
</strong>
~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.
</p>

		</section>
		<section id="canonical-urls">
<h3 title="Canonical URLs">5.4. 正準的~URL</h3>

<p>
`§ 課題なり得るもの＠#disadvantages$にて要旨したとおり、
<strong>
~serverは、
資源への~accessを供するために利用される能力~URLが複数あるときには，その資源~用に単独の正準的~URLを有するべきである。
</strong>
この~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).
</p>

<p>
正準的~URLは、
次に利用し得る：
◎
Canonical URLs may be used:
</p>

<ul>
	<li>
資源~用の能力~URLを~listして，それらの作成に対する制御を供する。
◎
to list and provide control over the creation of capability URLs for the resource
</li>
	<li>
資源が公になるとき，遷移される~URLとして。
◎
as a URL that is transitioned to when a resource becomes public
</li>
	<li>
誰もが制限付き特権で~accessできる公な~URLとして。
◎
as a public URL that anyone can access with limited privileges
</li>
	<li>
誰もが資源についての注釈に利用できる共通な~URLとして。
◎
as a common URL that can be used by anyone in annotations about the resource
</li>
</ul>

<p>
能力~URLを通して~accessされる~pageが内容を直に~serveする場合、
そのような~pageは，当の資源~用の正準的~URLへ~linkできる
— ~pageの~metadata（ `link$e 要素）において
<code>`rel^a="`canonical$v"</code>
を通して，あるいは資源の `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 &lt;link&gt; element) or within a Link header on the resource.
</p>

<p>
<strong>
能力~URLが指す資源が後で公にされた場合、
`301$st `Moved Permanently^ph で応答して，［
通常の公な正準的~URL
］への~redirectionを供するべきである。
</strong>

◎
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.
</p>

		</section>
	</section>
	<section id="future-work" class="appendix">
<h2 title="A. Future Work">将来の作業</h2>

<p>
~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:
</p>

<ul>
	<li>
`Content Security Policy＠~CSP3$ 指令
◎
a Content Security Policy directive
</li>
	<li>
要請に対する応答~内の~HTTP~header
◎
an HTTP header in responses to a request
</li>
	<li>
能力~URLへの~linkに対する~link関係（特に，~email~messageの中で）
◎
a link relation on links to the capability URLs (particularly within email messages)
</li>
	<li>
~URLの中の認識される文字列
◎
a recognised string within URLs
</li>
</ul>

<p>
~browserや~email~clientは、
次に挙げるような様々な仕方で~URLを保護することもできる：
◎
A browser or email client could then protect the URL in various ways such as:
</p>

<ul>
	<li>
~URL~barを隠蔽する
◎
obscuring the location bar
</li>
	<li>
`Referer$h ~headerに設定されないことを確保する
◎
ensuring that the Referer header was not set
</li>
	<li>
第三者-主体~scriptから当の~page~URLへの~accessは許容しない
◎
disallowing access to the page URL from any third-party scripts
</li>
	<li>
履歴の中にある それを隠す
◎
hiding it within the history
</li>
	<li>
~accountが弱体化された疑いがある場合には、
~accessを差止める
◎
sequestering access if there's suspicion that an account has been compromised
</li>
</ul>

	</section>
	<section id="acknowledgements">
<h2 title="Acknowledgements">謝辞</h2>

<p>
この文書に対する変更を示唆された `Noah Mendelsohn^en 氏に特に謝意を。
◎
Thanks in particular to Noah Mendelsohn for his suggested changes to this document.
</p>

	</section>
</main></div>