Identity

TL; DR:

すべてのユーザーは、alice.host.com または単に alice.com のようなドメイン名を持っています。

また、各ユーザーはホスト間の移行を可能にする永続的な「DID」を持っている

DIDは、ユーザーのキーとホストアドレスにマッピングされます。

atprotoのIDシステムには、いくつかの要件があります：

このシステムを採用することで、アプリケーションはエンドツーエンドの暗号化、署名付きユーザーデータ、サービスサインイン、一般的な相互運用のためのツールを得ることができます。

以下は、すべて有効なユーザー識別子です:

alice.host.com

at://alice.host.com

at://did:plc:bv6ggog3tya2z3vxsub7hnal

それらの間の関係は、次のように視覚化できます。

code:txt

┌──────────────────┐ ┌───────────────┐

│ DNS name ├──resolves to──→ │ DID │

│ (alice.host.com) │ │ (did:plc:...) │

└──────────────────┘ └─────┬─────────┘

↑ │

│ resolves to

│ │

│ ↓

│ ┌───────────────┐

└───────────references───────┤ DID Document │

│ {"id":"..."} │

└───────────────┘

DNS ハンドルはユーザー向けの識別子です。ユーザーを見つける方法として UI に表示し、宣伝する必要があります。 アプリケーションはハンドルを DID に解決し、DID を安定した正規識別子として使用します。 DID は、公開鍵とユーザー サービスを含む DID documentに安全に解決できます。

DID に関連付けられたハンドル。

署名鍵

ユーザのPDSのURL

DID メソッド

Handle の解決

ATP のhandleは、DID に解決(resolve)されるドメイン名であり、DID は、ユーザーの署名公開鍵とホスティング サービスを含む DID Documentに解決されます。

疑似TypeScriptのアルゴリズムは次のとおりです。

code:ts

async function resolveHandle(handle: string) {

const res = await xrpc(origin, 'com.atproto.identity.resolveHandle', {handle})

assert(typeof res?.did === 'string' && res.did.startsWith('did:'))

return res.did

}

例:ホスティングサービス

ホスティング サービスが PLC を使用していて、ユーザーのハンドルをサブドメインとして提供しているシナリオを考えてみましょう。

code:ts

次に、返されたDIDに対してPLC解決メソッドを呼び出し、ホスティングサービスのエンドポイントとユーザーのキーマテリアルを知ることができるようにします。

code:ts

await didPlc.resolve('did:plc:12345') /* => {

id: 'did:plc:12345',

}*/

例:ホスティングサービス(ドメイン分離型)

ユーザーが独自のドメイン名を提供したことを除いて、前と同じシナリオがあるとします。

code:ts

そして、先ほどと同じようにDIDを解決します：

code:ts

await didPlc.resolve('did:plc:12345') /* => {

id: 'did:plc:12345',

}*/

例:セルフホスト

セルフホスティングのシナリオを考えてみましょう。 did:plc を使用すると、次のようになります。

ただし、セルフホスティング事業者がドメイン名の所有権を保持すると確信している場合は、did:plc の代わりに did:web を使用できます。

code:ts

次に、did:web を使用して解決します。

code:ts

await didWeb.resolve('did:web:alice.com') /* => {

id: 'did:web:alice.com',

}*/