diff --git a/sp800-63-3/sec1_2_introduction.ja.md b/sp800-63-3/sec1_2_introduction.ja.md
index 50883b33..06e20233 100644
--- a/sp800-63-3/sec1_2_introduction.ja.md
+++ b/sp800-63-3/sec1_2_introduction.ja.md
@@ -32,7 +32,7 @@ Digital Authentication は, 個人の情報への Unauthorized Access のリス
 
 <!-- Digital authentication supports privacy protection by mitigating risks of unauthorized access to individuals' information. At the same time, because identity proofing, authentication, authorization, and federation involve the processing of individuals' information, these functions can also create privacy risks. These guidelines therefore include privacy requirements and considerations to help mitigate potential associated privacy risks. -->
 
-本ガイドライン群は, Identity Assurance を個別要素ごとに分割することで, Authentication の誤りがもたらすネガティブインパクトの軽減に寄与する. Non-federated なシステムでは, 各機関はそれらのうち *Identity Assurance Level (IAL)* と *Authenticator Assurance Level (AAL)* という2つの要素を用いるであろう. Federated なシステムでは, それに加えて3つ目の要素となる *Federation Assurance Level (FAL)* も用いることとなろう. [Section 5, Digital Identity Risk Management](#sec5) では Risk Assesment プロセスの詳細について述べる. [Section 6, Selecting Assurance Levels](#sec6) は, Risk Assessment の結果と追加のコンテキストをふまえ, 機関によるリスクに応じた適切な IAL, AAL, FAL の選択の一助となる.
+本ガイドライン群は, Identity Assurance を個別要素ごとに分割することで, Authentication の誤りがもたらすネガティブインパクトの軽減に寄与する. Non-federated なシステムでは, 各機関はそれらのうち *Identity Assurance Level (IAL)* と *Authenticator Assurance Level (AAL)* という2つの要素を用いるであろう. Federated なシステムでは, それに加えて3つ目の要素となる *Federation Assurance Level (FAL)* も用いることとなろう. [Section 5, Digital Identity Risk Management](#sec5) では Risk Assessment プロセスの詳細について述べる. [Section 6, Selecting Assurance Levels](#sec6) は, Risk Assessment の結果と追加のコンテキストをふまえ, 機関によるリスクに応じた適切な IAL, AAL, FAL の選択の一助となる.
 
 <!-- These guidelines support the mitigation of the negative impacts induced by an authentication error by separating the individual elements of identity assurance into discrete, component parts. For non-federated systems, agencies will select two components, referred to as *Identity Assurance Level (IAL)* and *Authenticator Assurance Level (AAL)*. For federated systems, a third component, *Federation Assurance Level (FAL)*, is included. [Section 5, Digital Identity Risk Management](#sec5) provides details on the risk assessment process. [Section 6, Selecting Assurance Levels](#sec6) combines the results of the risk assessment with additional context to support agency selection of the appropriate IAL, AAL, and FAL combinations based on risk. -->
 
@@ -56,7 +56,7 @@ SP 800-63 は以下のような一連の Vol. から構成される.
 
 <!-- As such, SP 800-63 is organized as a suite of volumes as follows: -->
 
-SP 800-63 *Digital Identity Guidelines*:　SP 800-63 では, Risk Assesment の方法論, デジタルシステムにおける Authenticator, Credential, Assertion を利用した一般的な Identity Framework の概観, およびリスクベースプロセスに基づく各 Assurance Level の選択方法について述べる. _SP 800-63 contains both normative and informative material._
+SP 800-63 *Digital Identity Guidelines*:　SP 800-63 では, Risk Assessment の方法論, デジタルシステムにおける Authenticator, Credential, Assertion を利用した一般的な Identity Framework の概観, およびリスクベースプロセスに基づく各 Assurance Level の選択方法について述べる. _SP 800-63 contains both normative and informative material._
 
 <!-- SP 800-63 *Digital Identity Guidelines*: Provides the risk assessment methodology and an overview of general identity frameworks, using authenticators, credentials, and assertions together in a digital system, and a risk-based process of selecting assurance levels. _SP 800-63 contains both normative and informative material._ -->
 
@@ -155,7 +155,7 @@ NIST SP 800-63-3 は SP 800-63-2 の大幅なアップデートと再構成を
 
 <!-- Other areas updated in 800-63-3 include: -->
 
-- Identity Proofing および Federation をスコープに含めていることを正しく示すべく, "Digital Identity Guidelines" に改名し, 将来のリビジョンで Device Identity や Machine-to-Machene Authentication を扱えるようスコープを拡大する余地を含めた.
+- Identity Proofing および Federation をスコープに含めていることを正しく示すべく, "Digital Identity Guidelines" に改名し, 将来のリビジョンで Device Identity や Machine-to-Machine Authentication を扱えるようスコープを拡大する余地を含めた.
 - Assertion 技術における *Token* との混同を避けるため *Token* の代わりに *Authenticator* という用語を用いるなど, 用語変更を行った.
 - Authentication および Assertion の要件を更新し, セキュリティー技術および脅威の進化を反映した.
 - Verifier が Long-term Secret を保管する際の要件を定めた.
diff --git a/sp800-63-3/sec4_model.ja.md b/sp800-63-3/sec4_model.ja.md
index 2c5e53ca..929892da 100644
--- a/sp800-63-3/sec4_model.ja.md
+++ b/sp800-63-3/sec4_model.ja.md
@@ -223,7 +223,7 @@ RP はその発信元, 生成日時, 生成後の有効期限, および CSP と
 
 <!-- An RP trusts an assertion based on the source, the time of creation, how long the assertion is valid from time of creation, and the corresponding trust framework that governs the policies and processes of CSPs and RPs. The verifier is responsible for providing a mechanism by which the integrity of the assertion can be confirmed. -->
 
-RP は発信元 (Verifier) を Authenticate し, Assertion の Integrity (完全性) を確認する義務を負う. Verifier が Subscriber を経由して Assertion を提供する場合には, Verifier は Assertion が改ざんされないよう, その Integirity (完全性) を保護しなければならない. 一方 Verifier が直接 RP と通信を行う場合, Protected Session によって Assertion の Integrity (完全性) を確保してもよい. オープンな Network を通じて Assertion を送信する場合, Verifier は, Assertion に含まれる Subscriber に関するセンシティブな情報が, 情報の Confidentiality (機密性) を保つという点において信頼に足る RP 以外の何者の手にも渡らないことを, 確かなものとする責任がある.
+RP は発信元 (Verifier) を Authenticate し, Assertion の Integrity (完全性) を確認する義務を負う. Verifier が Subscriber を経由して Assertion を提供する場合には, Verifier は Assertion が改ざんされないよう, その Integrity (完全性) を保護しなければならない. 一方 Verifier が直接 RP と通信を行う場合, Protected Session によって Assertion の Integrity (完全性) を確保してもよい. オープンな Network を通じて Assertion を送信する場合, Verifier は, Assertion に含まれる Subscriber に関するセンシティブな情報が, 情報の Confidentiality (機密性) を保つという点において信頼に足る RP 以外の何者の手にも渡らないことを, 確かなものとする責任がある.
 
 <!-- The RP is responsible for authenticating the source (the verifier) and for confirming the integrity of the assertion. When the verifier passes the assertion through the subscriber, the verifier must protect the integrity of the assertion in such a way that it cannot be modified. However, if the verifier and the RP communicate directly, a protected session may be used to preserve the integrity of the assertion. When sending assertions across an open network, the verifier is responsible for ensuring that any sensitive subscriber information contained in the assertion can only be extracted by an RP that it trusts to maintain the information's confidentiality. -->
 
diff --git a/sp800-63-3/sec5_DIRM.ja.md b/sp800-63-3/sec5_DIRM.ja.md
index 666e70ad..0d52699b 100644
--- a/sp800-63-3/sec5_DIRM.ja.md
+++ b/sp800-63-3/sec5_DIRM.ja.md
@@ -46,7 +46,7 @@ RMF の全体的な適用を支援するため, [Section 5.3](#section5-3) に
 
 <!-- [Section 5.3](#section5-3) provides impact categories specific to digital identity to assist in the overall application of the RMF. -->
 
-Risk Assesment は, Identity Proofing, Authentication, Federation の各プロセスにおいて, どのようなリスクを軽減するべきかを決定するものである. こういった決定は, リスク明確化に役立つ技術への欲求を引き起こすものではなく, 適用可能な技術とリスク軽減策の選択を推進するものである. ひとたび機関が全体の Risk Assessment を終え, Identity Proofing, Authentication, (および該当する場合は) Federation それぞれに対する Assurance Level を選択し, それぞれの Assurance Level を満たすために採用すべきプロセスや技術を選定すると, 機関は [SP 800-53A](#SP800-53A) IA-1 a.1 に従い "Digital Identity Acceptance Statement" を策定すること (SHALL). [Section 5.5](#daps) に "Digital Identity Acceptance Statement" に必要なコンテンツを詳説する.
+Risk Assessment は, Identity Proofing, Authentication, Federation の各プロセスにおいて, どのようなリスクを軽減するべきかを決定するものである. こういった決定は, リスク明確化に役立つ技術への欲求を引き起こすものではなく, 適用可能な技術とリスク軽減策の選択を推進するものである. ひとたび機関が全体の Risk Assessment を終え, Identity Proofing, Authentication, (および該当する場合は) Federation それぞれに対する Assurance Level を選択し, それぞれの Assurance Level を満たすために採用すべきプロセスや技術を選定すると, 機関は [SP 800-53A](#SP800-53A) IA-1 a.1 に従い "Digital Identity Acceptance Statement" を策定すること (SHALL). [Section 5.5](#daps) に "Digital Identity Acceptance Statement" に必要なコンテンツを詳説する.
 
 <!-- Risk assessments determine the extent to which risk must be mitigated by the identity proofing, authentication, and federation processes. These determinations drive the relevant choices of applicable technologies and mitigation strategies, rather than the desire for any given technology driving risk determinations. Once an agency has completed the overall risk assessment; selected individual assurance levels for identity proofing, authentication, and federation (if applicable); and determined the processes and technologies they will employ to meet each assurance level, agencies SHALL develop a "Digital Identity Acceptance Statement", in accordance with [SP 800-53A](#SP800-53A) IA-1 a.1. See [Section 5.5](#daps) for more detail on the necessary content of the Digital Identity Acceptance Statement. -->
 
diff --git a/sp800-63-3/sec6_xAL.ja.md b/sp800-63-3/sec6_xAL.ja.md
index 59cea25b..4ce30cd3 100644
--- a/sp800-63-3/sec6_xAL.ja.md
+++ b/sp800-63-3/sec6_xAL.ja.md
@@ -127,7 +127,7 @@ Risk Assessment の結果は最適なレベル選択における第一の要素
 
 </table> -->
 
-リスクを分析するにあたり, 機関は, 何らかの失敗を引き起こしたり人・組織に損害を及ぼす可能性を含む, 予想される Authenticatino 失敗の直接的および間接的な結果のすべてを考慮しなければならない (SHALL). 潜在的な影響の定義には, 意味がコンテキストに依存する "相当" または "軽微" のような相対的な用語が含まれる. 機関はこういった被害の相対的重要性を決定するために, 影響を受ける人や主体のコンテキストや性質を考慮すべきである (SHOULD). 時間が経つにつれて, 機関はこれらの問題に関する実践的な経験を得ることとなり, これらの用語の意味はより明確になるであろう. 機関のプログラムや公共の利益に対する被害の分析はコンテキストに強く依存するため, 機関はこれらの問題を注意深く考慮すべきである (SHOULD).
+リスクを分析するにあたり, 機関は, 何らかの失敗を引き起こしたり人・組織に損害を及ぼす可能性を含む, 予想される Authentication の失敗の直接的および間接的な結果のすべてを考慮しなければならない (SHALL). 潜在的な影響の定義には, 意味がコンテキストに依存する "相当" または "軽微" のような相対的な用語が含まれる. 機関はこういった被害の相対的重要性を決定するために, 影響を受ける人や主体のコンテキストや性質を考慮すべきである (SHOULD). 時間が経つにつれて, 機関はこれらの問題に関する実践的な経験を得ることとなり, これらの用語の意味はより明確になるであろう. 機関のプログラムや公共の利益に対する被害の分析はコンテキストに強く依存するため, 機関はこれらの問題を注意深く考慮すべきである (SHOULD).
 
 <!-- In analyzing risks, the agency SHALL consider all of the expected direct and indirect results of an authentication failure, including the possibility that there will be more than one failure, or harms to more than one person or organization. The definitions of potential impacts contain some relative terms, like "serious" or "minor," whose meaning will depend on context. The agency SHOULD consider the context and the nature of the persons or entities affected to decide the relative significance of these harms. Over time, the meaning of these terms will become more definite as agencies gain practical experience with these issues. The analysis of harms to agency programs or other public interests depends strongly on the context; the agency SHOULD consider these issues with care. -->
 
@@ -196,7 +196,7 @@ IAL 選択の実施は, 当該デジタルサービス提供者が Proofing を
   </tr>
   <tr>
     <td>
-      この段階では, 機関はある程度の Proofing が必要であることは理解していることになる. Step 3 は, IAL2 と IAL3 のどちらが最適な選択かを決定するために, Identity Proofing が失敗した際の潜在的影響に着目している. 機関が陥る可能性のある主な Idetity Proofing 失敗は, 偽造された Identity を真として受け入れてしまうことである. これによりサービスや利益を間違った人物や不適格な人物に提供してしまうことになる. さらに, Proofing が必要ない場合や必要以上に多くの情報を収集してしまった場合, それ自体がリスクとなりうる. 従って必要がないのに検証済 Attribute を取得することも, Identity Proofing の失敗であるとみなされる. このステップでは, サービス提供の為に Personal Information が必要であるかどうか察知し, 機関が Step 1 および 2 に誤って回答していないかどうかを検知すべきである. 片方にはネガティブな影響がない場合でも, もう一方には著しい被害が及ぶ可能性もあるため, リスクは組織およびユーザーの両方の視点で考慮すべきである. 機関の Risk Management プロセスはこのステップから開始されるべきである.
+      この段階では, 機関はある程度の Proofing が必要であることは理解していることになる. Step 3 は, IAL2 と IAL3 のどちらが最適な選択かを決定するために, Identity Proofing が失敗した際の潜在的影響に着目している. 機関が陥る可能性のある主な Identity Proofing 失敗は, 偽造された Identity を真として受け入れてしまうことである. これによりサービスや利益を間違った人物や不適格な人物に提供してしまうことになる. さらに, Proofing が必要ない場合や必要以上に多くの情報を収集してしまった場合, それ自体がリスクとなりうる. 従って必要がないのに検証済 Attribute を取得することも, Identity Proofing の失敗であるとみなされる. このステップでは, サービス提供の為に Personal Information が必要であるかどうか察知し, 機関が Step 1 および 2 に誤って回答していないかどうかを検知すべきである. 片方にはネガティブな影響がない場合でも, もう一方には著しい被害が及ぶ可能性もあるため, リスクは組織およびユーザーの両方の視点で考慮すべきである. 機関の Risk Management プロセスはこのステップから開始されるべきである.
     </td>
     <!-- <td>At this point, the agency understands that some level of proofing is required. Step 3 is intended to look at the potential impacts of an identity proofing failure to determine if IAL2 or IAL3 is the most appropriate selection. The primary identity proofing failure an agency may encounter is accepting a falsified identity as true, therefore providing a service or benefit to the wrong or ineligible person. In addition, proofing, when not required, or collecting more information than needed is a risk in and of itself. Hence, obtaining verified attribute information when not needed is also considered an identity proofing failure. This step should identify if the agency answered Step 1 and 2 incorrectly, realizing they do not need personal information to deliver the service. Risk should be considered from the perspective of the organization and to the user, since one may not be negatively impacted while the other could be significantly harmed. Agency risk management processes should commence with this step.</td> -->
   </tr>
diff --git a/sp800-63b/sec4_aal.ja.md b/sp800-63b/sec4_aal.ja.md
index 6a8d3c98..689211f2 100644
--- a/sp800-63b/sec4_aal.ja.md
+++ b/sp800-63b/sec4_aal.ja.md
@@ -7,7 +7,7 @@ _本セクションは標準及び参考情報の題材両方を含む._
 _This section contains both normative and informative material._
 -->
 
-指定されたAALの要件を満たすために，Claimantは少なくとも自身がSubscriberとして認識される強度のレベルでAuthenticateされるものとする(SHALL)．Authenticationプロセスの結果は識別子であり，SubscriberがRPに対してAuthenticateするたびに使われるものとする(SHALL)．それは仮名でもよい(MAY)，Subscriberの識別子は異なる目的で再利用すべきではない(SHOULD NOT)が，CSPによって過去に登録済みのSubjectが再登録される場合には再利用すべきである(SHOULD)．Subscriberをを一意なSubjectであると識別する他の属性もまた提供されてもよい(MAY)．
+指定されたAALの要件を満たすために，Claimantは少なくとも自身がSubscriberとして認識される強度のレベルでAuthenticateされるものとする(SHALL)．Authenticationプロセスの結果は識別子であり，SubscriberがRPに対してAuthenticateするたびに使われるものとする(SHALL)．それは仮名でもよい(MAY)，Subscriberの識別子は異なる目的で再利用すべきではない(SHOULD NOT)が，CSPによって過去に登録済みのSubjectが再登録される場合には再利用すべきである(SHOULD)．Subscriberを一意なSubjectであると識別する他の属性もまた提供されてもよい(MAY)．
 
 <!--
 To satisfy the requirements of a given AAL, a claimant SHALL be authenticated with at least a given level of strength to be recognized as a subscriber. The result of an authentication process is an identifier that SHALL be used each time that subscriber authenticates to that RP. The identifier MAY be pseudonymous. Subscriber identifiers SHOULD NOT be reused for a different subject but SHOULD be reused when a previously-enrolled subject is re-enrolled by the CSP. Other attributes that identify the subscriber as a unique subject MAY also be provided.
@@ -470,4 +470,4 @@ Requirement | AAL1 | AAL2 | AAL3
 **Authentication intent** | Not required | Recommended | Required |
 **Records Retention Policy** | Required | Required | Required |
 **Privacy Controls** | Required | Required | Required |
--->
\ No newline at end of file
+-->
diff --git a/sp800-63c/sec7_presentation.ja.md b/sp800-63c/sec7_presentation.ja.md
index f17eec2a..8ac74f94 100644
--- a/sp800-63c/sec7_presentation.ja.md
+++ b/sp800-63c/sec7_presentation.ja.md
@@ -8,7 +8,7 @@ Assertion は IdP から RP に対して *Back-Channel* ないしは *Front-Chan
 
 <!-- Assertions MAY be presented in either a *back-channel* or *front-channel* manner from the IdP to the RP. There are tradeoffs with each model, but each requires the proper validation of the assertion. Assertions MAY also be proxied to facilitate federation between IdPs and RPs under specific circumstances, as discussed in [Section 5.1.4](#proxied). -->
 
-IdP は RP が明示的に要求した Attribute のみを送信することとする (SHALL). また RP は Privacy Risk Assesment を行い, どの Attribute を要求するか決定することとする (SHALL).
+IdP は RP が明示的に要求した Attribute のみを送信することとする (SHALL). また RP は Privacy Risk Assessment を行い, どの Attribute を要求するか決定することとする (SHALL).
 
 <!-- The IdP SHALL transmit only those attributes that were explicitly requested by the RP. RPs SHALL conduct a privacy risk assessment when determining which attributes to request. -->