Self-Issued OpenID Connect Provider DID Profile読んでみた
DIF Working Group の Self-Issued OpenID Connect Provider DID Profile （SIOP DID Profile） を読んでみたので、自分用にメモを残します。
前提として、 SIOP DID Profile は intermediate hubs や cloud agents を明示的にサポートしていない仕様であり、DID を交換するためのプロトコルです。
This specification does not explicitly support any intermediate hubs or cloud agents. It is meant to be a protocol to exchange the DID. You could then interact with a hub/ cloud agent using the service endpoint in the DID Document.
DID を交換した後に、DID Document のサービスエンドポイントを利用して、 hub / cloud agent とのやりとりをおこなう必要があるようです。
詳しくは以下の Aries RFC 0046: Mediators and Relays や Aries RFC 0094: Cross-Domain Messaging あたりを参照すると良いかもしれません。
SIOP DID Profile の実装も用意されているので別途試してみようと思います。（2020/02/03時点ではまだ開発中で途中までしか試せなかった…）
Protocol Flow
SIOP DID Profile において、以下のフローが示されています。
特筆すべき点としては、Authorization Code Flowではなく、Implicit Flow になっている点があります。
これは、OpenID Connect Core 1.0（OIDC.Core）における SIOP の仕様上、response_typeが id_token 固定であるためと考えられます。
response_type
REQUIRED. Constant string value id_token.
（引用元: https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedRequest）Generate SIOP Request
SIOP に対する認可リクエストについてです。
openid://?response_type=id_token
&client_id=https%3A%2F%2Frp.example.com%2Fcb
&scope=openid%20did_authn
&request=<JWT>SIOP は Native Application として動作していることが想定されるため、 openid:// というカスタムスキームを利用してリダイレクトすることで Mobile Browser から SIOP を呼び出します。
また、SIOP では Client 登録が不要であるため、 client_id にredirect_uri となる値が設定されています。
client_id
redirect_uri value of the Client.
（引用元: https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedRegistration）各パラメーターについては、OIDC.Core の 7.3. Self-Issued OpenID Provider Request を参照します。
SIOP DID Profile では Request Object の定義が追加されているため、OIDC.Core の 6.1. Passing a Request Object by Value との差分を確認します。
SIOP DID Profile で定義されている Request Object のサンプルは次のとおりです。
(Header)
{
"alg": "ES256K",
"typ": "JWT",
"kid": "did:example:0xab#veri-key1"
}(Payload)
{
"iss": "did:example:0xab",
"response_type": "id_token",
"client_id": "https://my.rp.com/cb",
"scope": "openid did_authn",
"state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj",
"response_mode" : "form_post",
"registration" : {
"jwks_uri" : "https://uniresolver.io/1.0/identifiers/did:example:0xab;transform-keys=jwks",
"id_token_signed_response_alg" : [ "ES256K", "EdDSA", "RS256" ]
}
}
OIDC.Core の Request Object から変更があったパラメーターを確認します。
iss (REQUIRED):
DID Document を解決するための RP の DID を含まなければならない (MUST)。また、DID Document は Request Object を検証するための verification method を含まなければならない (MUST) 。
kid (REQUIRED):
verification method を参照する DID URL でなければならない (MUST)
scope (REQUIRED):
did_authn を含まなければならない (MUST)。
registration (REQUIRED):
kid と同じ kid が含まれていなければならない (MUST)。
did_doc (OPTIONAL):
iss claim の DID に対応する DID Document を含まなければならない (MUST)。
response_mode (OPTIONAL):
SIOP のコールバック URL に対するレスポンス方法を指定する。この仕様を実装する SIOP は response_mode を form_post に設定してもよい (MAY)。
SIOP Request Validation
SIOP Request の検証についてです。
SIOPは SIOP Request の scope に did_authn が含まれている場合、次のとおり検証する必要があります (MUST) 。
・did_doc が存在しない場合、iss で指定された RP の DID から DID Document を解決する。
・did_doc が存在する場合、適切な DID method にしたがって RP の DID Document を交換することが可能な経路であるか確認する。
・jwks_uri が存在する場合、jwks_uri の DID が iss claim の DID と一致することを確認する。
・SIOP Request の kid と一致する RP の DID Document から verification method を決定する。
・verification method にしたがって SIOP Request を検証する。
Generate SIOP Response
SIOP の 認可レスポンスについてです。
SIOP DID Profile に記載されている SIOP Response の id_token のサンプルは次のとおりです。
(Header)
{
"alg": "ES256K",
"typ": "JWT",
"kid": "did:example:0xab#key-1"
}(Payload)
{
"iss": "https://self-issued.me",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"sub_jwk" : {
"crv":"secp256k1",
"kid":"did:example:0xcd#verikey-1",
"kty":"EC",
"x":"7KEKZa5xJPh7WVqHJyUpb2MgEe3nA8Rk7eUlXsmBl-M",
"y":"3zIgl_ml4RhapyEm5J7lvU-4f5jiBvZr4KgxUjEhl9o"
},
"sub": "9-aYUQ7mgL2SWQ_LNTeVN2rtw7xFP-3Y2EO9WV22cF0",
"did": "did:example:0xcd"
}
iss の https://self-issued.me は SIOP の Issuer 識別子であり、OIDC.Core 7. Self-Issued OpenID Provider に記載されています。
基本的には OIDC.Core の 7.4. Self-Issued OpenID Provider Response と同様の形式になっています。
id_token の claim に一部変更があるようなので確認をします。
sub_jwk (REQUIRED): id_token の 検証に利用。SIOP の DID Document 内の valification method を参照する DID URL である kid を含まなければならない (MUST) 。
did (REQUIRED):
SIOP の DID でなければならない(MUST) 。
did_doc (OPTIONAL):
did に対応する SIOP の DID ドキュメントでなければならない (MUST) 。
SIOP Response Validation
SIOP Response の検証についてです。
RPは SIOP Response を OIDC.Core 7.5. Self-Issued ID Token Validation にしたがって検証し、さらに PR は次のように SIOP の DID Document に対して id_token を検証する必要があります。 (MUST) 。
・did_doc が存在しない場合、did claim で指定された SIOP の DID から DID Document を解決します。
・did_doc が存在する場合、適切な DID method にしたがって SIOPの DID Document を交換することが可能な経路であるか確認する。
・id_token の sub_jwk claim の kid に一致する SIOP の DID Document から valification method を決定する。
・verification method にしたがって id_token を検証する。
おわりに
今回は DIF Working Group の SIOP DID Profile を読み、SIOP Request / Response に関する箇所についてメモを残しました。
今度は実際に実装を確認できたら良いかなと思っています。
また、他にも SIOP 関連の仕様として次のものもあるので合わせて読んで比較できると良いかなと思っています。https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/final-documents/did-auth-oidc.pdf
参考
https://identity.foundation/did-siop/
https://openid.net/specs/openid-connect-core-1_0.html
https://github.com/hyperledger/aries-rfcs
