FDO認証は、他のFIDOアライアンス認証プログラムから独立しています。
FDO認証取得への道は、製品開発後に始まる。 製品開発はFDO認証の範囲外です。 認証を申請する前に、すべてのFDO仕様書、認証要件、およびポリシーをお読みください。 実装者ガイダンス文書およびFDO開発者フォーラムは、製品開発サポートのための利用可能なリソースである。
以下の表は、各製品の認証に必要な手順を示しています。 詳細はステップを選択してください。
FDO実装クラス
デバイスオンボーディング(DO)サービス | デバイス/FDO対応デバイス | ランデブーサーバー(RV) | |
ステップ1:申し込み | |||
認証NDA | |||
ステップ2:適合性テスト | |||
ステップ3:相互運用性テスト | |||
ステップ4:セキュリティ評価 | 該当なし | ||
レベル1 (L1) VQ | 該当なし | ||
ステップ 5: 認証リクエスト | |||
認証料の請求と支払い | |||
ステップ6:証明書の発行 | |||
TMLA | |||
ステップ7:認証の維持 | |||
デリバティブ | |||
デルタ | 該当なし | ||
再認証 | 該当なし |
ステップ1:申し込み

FDO認証プロセスを開始するには、ベンダーがFDO認証申請書に記入する必要があり、FIDO認証事務局が承認し、受領を確認します。 このアプリケーションは、FIDO認証に認証ベンダーに関する管理上の詳細を提供するとともに、FDO認証を求める実装に関する一般的な情報を提供することを目的としています。
認定申請書はこちらから入手できる。
さらに、認証会社がまだ記入していない場合、ベンダーはFIDO認証秘密保持契約(NDA)に記入し、認証事務局( certification@fidoalliance.org)に提出する必要があります。
ステップ2:適合性テスト

ベンダーは、FDO認証を求める実装について、テストツールを使用し、結果をFIDO認証事務局に提出することで、FDO適合性テストを自己管理し、正常に完了します。
FDO適合性テストの詳細については、機能認証プログラムのページを参照してください。
ステップ3:相互運用性テスト

FDO適合性テストが正常に完了すると、ベンダーはFDO認証を求める実装についてFDO相互運用性テストを登録し、正常に完了します。
今後のFDO相互運用性テストイベントのスケジュールやイベント登録のリンクなど、FDO相互運用性テストの詳細については、機能認定プログラムのページを参照してください。
ステップ4:セキュリティ評価

セキュリティ評価ステップは、デバイスオンボーディングサービスとデバイスを認証するために必要です。 ランデブーサーバーは、セキュリティ認証の完了が免除されます。
FDO 相互運用性試験を完了した後、ベンダーは認証製品 1 つにつき FDO ベンダー質問書(VQ)を 1 回記入しなければならない。 完成したVQは、fdo-security-evaluation@fidoalliance.org。
FIDOセキュリティ事務局は、提出されたVQの受領を確認し、受領された順序に基づいて各VQを審査する。 安全保障事務局は、追加的な説明や詳細を要求することがある。 評価が成功すると、セキュリティ事務局はVQを承認済みとマークし、ベンダーと認証事務局に通知します。
ステップ 5: 認証リクエスト

ベンダーは、FIDO認証事務局から、該当する認証テストおよび/または評価ステップがすべて完了したら、認証リクエストを提出するよう求められます。
ランデブーサーバー
機能認証要件が正常に完了すると、認証事務局は、完了したすべての認証手順を確認する電子メールを送信し、ベンダーに認証リクエストの完了を要求します。
デバイスオンボーディングサービスとFDO対応デバイス
機能要件とセキュリティ要件が正常に完了した後、認証事務局は、完了したすべての認証手順を確認する電子メールを送信し、ベンダーに認証要求の完了を要求します。
認証リクエストは、ベンダーとFIDOアライアンスの間で完了する請求プロセスをトリガーします。 ベンダーから支払いを受領した時点で、認証事務局は証明書の発行を完了します。
ステップ6:証明書の発行

認証事務局は、入金を受領後、認証製品ごとにFDO証明書を作成し、各証明書を電子メールでベンダーに発行します。 この際、認証会社がまだ完了していない場合は、販売者が FIDOⓇ 認証ロゴの使用を希望する場合、販売者は FIDO 商標ライセンス契約(TMLA)を完了するよう要請される。 TMLAを完全に履行するためには、TMLAのバージョンごとに1社につき1つのTMLAが必要です。 また、認証事務局は、FDO証明書の一部として同封されている製品および会社のフィールドの正確性を確認するようベンダーに依頼します。 変更が必要な場合、ベンダーは、3営業日以内に、変更点を明記した電子メールによる回答を求める。
FDO認証の詳細を確認した後、認証事務局はFDO認証製品証明書をFIDO認証製品データベースにアップロードします。
ステップ7:認証の維持

FIDO®認定製品には、随時変更が加えられることがあります。 ランデブーサーバーはライセンスまたは販売される可能性があり、その結果、派生認証のメンテナンスを完了する必要があります。 デバイスオンボーディングサービスおよびFDO対応デバイスは、FDOセキュリティ要件に関連する変更の影響を受ける可能性があり、その結果、非干渉、マイナー、またはメジャーに分類され、デリバティブ、デルタ、および再認証に関連する変更の評価を完了する必要があります。
認証メンテナンスには、すべてのFIDO®認証製品の要件が含まれており、製品ライフサイクル全体にわたって持続します。 FIDO®認証製品のベンダーは、認証の維持を通じて認証を遵守し、維持する必要があります。 完全な認証維持、ベンダーの義務、および認証失効情報については、認証プログラム・ポリシー文書を参照すること。
認証メンテナンスプロセスは、FDO 実装クラスによって説明されています。
ランデブーサーバー
FIDO®認定ランデブーサーバーの認証メンテナンスは、RVサーバーコンポーネントの非干渉、関連、派生認証を必要とする非干渉として分類された変更を検証するプロセスで構成されます。 このプロセスは1つのステップで構成されている。 派生認証の利点は、認証実装が機能認証テストを受ける必要がなく、各派生認証は基本認証よりも低い料金の対象となることです。
次のシナリオは、実装が派生認証の資格があるかどうかを判断するのに役立つように設計されています。
FIDO® 認定実装 – Rendezvous Server | デリバティブ? |
B社は、ベース認証を完了したA社の一般公開されているFIDO®認証ランデブーサーバーを使用しており、B社が使用する実装は変更されていない。 | はい |
基本認証を完了したA社がライセンスまたは販売したFIDO®認証ランデブーサーバーを使用し、B社が使用する実装に変更がないB社 | はい |
B 社が、他社の FIDO® Certified Rendezvous Server コンポーネントに関連する FIDO® Certified Logo を自社の Web サイトで使用している場合。 | はい |
FIDO®認定導入企業【Product v1.0】を導入し、Product 1.0とは異なる新製品【新製品v2.0】を発表しますが、FIDO®認定ランデブーサーバーのコンポーネントは変更されていません | はい |
FIDO®認定の導入企業[製品v1.0]を導入し、FIDO®認定ランデブーサーバーコンポーネントの変更など、製品1.0とは異なる新製品[新製品v2.0]を発表 | いいえ |
FIDO®認定ランデブーサーバーの派生認証を申請するには、ベンダーは、認証製品の基本証明書番号を含むランデブーサーバー派生認証リクエストフォームに記入する必要があります。
デバイスオンボーディングサービスとFDO対応デバイス
FIDO®認定デバイスオンボーディングサービスおよびFDO対応デバイスの認証メンテナンスは、非干渉、軽微、またはメジャーのいずれかに分類される変更を検証するマルチステッププロセスで構成されています。 これらの変更はFDOのセキュリティ要件に影響を与える可能性がある。 このような変更は、発見された欠陥を修正するために設計されたパッチ、機能の強化、新機能の追加、または FIDO® 認証 FDO ハードウェアおよび/またはソフトウェアに対するその他の変更である場合があります。
ステップ #1: 認証維持評価
このような変更の影響を評価するため、ベンダーはFDO影響分析報告書(FIAR)に記入する必要があります。 FIARフォームの一部として、変更の説明と認証製品の出所認証番号が提出され、FIDOセキュリティ事務局がこれを評価する。 記載された変更が分析され、FDOのセキュリティ要件適用範囲への影響が決定される。 セキュリティ事務局は、認証製品に加えられた変更の特徴に基づいて判定を行う。 その結果、変更は「NON-INTERFERING」、「MINOR」、「MAJOR」のいずれかとなり、それぞれ「Derivative」、「Delta」、「Recertification」のいずれかとなる。
デバイスオンボーディングサービスおよびFDO対応デバイス認証のメンテナンスを申請するには、ベンダーはFIARフォームに記入する必要があります。
安全保障事務局は、提出されたFIARフォームの受領を確認し、受領された順番に基づいて各FIARフォームを審査する。 安全保障事務局は、追加的な説明や詳細を要求することがある。 評価終了後、安全保障事務局は、機密変更の種類に印を付け、承認または拒否を明記する。
ステップ #2: 認証メンテナンスのリクエスト
FIARの評価結果に基づいている:
デリバティブ認証の場合、ベンダーはデリバティブ/デルタ認証リクエストフォームに記入する必要があります。
デルタ認証では、評価された変更が製品の機能特性に影響を与えないことを確認するため、ベンダ ーはまず適合性試験と相互運用性試験のステップを完了することが要求される。 正常に完了すると、ベンダーはデリバティブ/デルタ認証リクエストフォームに記入するよう求められます。
再認証の場合、ベンダーは認証プロセスを開始するよう要請される。
デリバティブ/デルタ認証リクエストは、ベンダーとFIDOアライアンスの間で請求処理が完了するトリガーとなります。 ベンダーから支払いを受領した時点で、認証事務局は証明書の発行を完了します。