ToppyMicroServices

RFC 8747 Quiz (JA)

CWT Proof-of-Possession Key Semantics

ENJA
0 / 0

参照（URL）

Q1: RFC 8747と整合するcnf profile ruleはどれか

Multiple Choice

A2A profileはproof of possessionを要求し,COSE_Key,Encrypted_COSE_Key,kid confirmation memberをsupportします.

**Explanation:** A: Section 3.1はcnf value内でCOSE_KeyとEncrypted_COSE_Keyのうち最大一つだけを認めます. B: Section 3.1はcnf valueが一つのproof-of-possession keyだけを表すとし,追加keyには別途定義したclaimを使います. C: 正解です.Section 3.1がone-key structureを定義し,required confirmation-member setはcontext dependentとします. D: Application requirementがない場合,Section 3.1はunrecognized confirmation memberをignoreさせます.

Q2: kidだけを含むcnfは何を確立するか

Multiple Choice

CWTはcnf={kid:h'01ab'}を含みます.recipientはまだkey lookupもA2A proof protocolも実行していません.

**Explanation:** A: Section 3.4はkidをapplication-specific identifierとし,recipientがidentified keyを取得してpossessionを確認できることを必要とします. B: Identifierはcopyできます.possessionは別のcryptographic protocolで確立します. C: Section 3.4はkidのinternal key encodingを定義しません. D: CWTのissuer protectionとpresenterによるconfirmation-key proofは別operationです.

Q3: resource serverはこのCWTをbearer tokenとして扱ってよいか

Multiple Choice

CWTはvalidで,cnfにCOSE_Keyを含みます.A2A profileはaccessをsender-constrainedとし,request nonceに対するfresh proofを要求します.resource serverはCWTをvalidateしましたが,confirmation keyによるsignature,MAC,その他proofを受け取っていません.

**Explanation:** A: cnf valueはissuerのconfirmation-key statementを運び,このrequestに対するpresenter proofではありません. B: Token-issuer authenticationとconfirmation-key possessionは,profileが同じkey/proofに安全に定義しない限り別です. C: Section 3.5はnonce communicationとproof transportをusing protocolへ意図的に委ねます. D: Sections 3.5 and 4はclaimed keyについてcurrentでreplay-resistantなproofをsurrounding protocolに要求します.指定A2A profileが判定基準です.

Q4: validatorはこのcnf valueをどう扱うべきか

Multiple Choice

protected CWTは同じcnf mapにCOSE_KeyとEncrypted_COSE_Keyを含みます.decode/decryptすると異なるpublic keyになります.profileは一つのunambiguous presenter keyを要求します.

**Explanation:** A: Section 3.1はこれらのmember間にprecedence ruleを定義しません. B: Section 3.1はCOSE_KeyとEncrypted_COSE_Keyのうち最大一つを認め,cnfが一つのproof-of-possession keyを表すとします. C: mapをalternativeとして扱うとdefined semanticsを変え,implementationごとに異なるkeyを選べます. D: CBOR map orderはconfirmation-method preference signalではありません.

Q5: signed-only CWTはこのsymmetric confirmation keyに十分か

Multiple Choice

issuerはkey valueを含むsymmetric COSE_Keyをcnfへ置き,CWTをsignしますがencryptしません.intermediaryはtokenを読めます.profileはそのsymmetric keyのexclusive possessionに依存します.

**Explanation:** A: Section 4はCWT内のsymmetric keyにorigin authentication/integrityだけでなくconfidentiality protectionも要求します. B: Signatureは変更をdetectしますが,signed payloadをconcealしません. C: Identifier追加はexposed key valueを除去も隠蔽もしません. D: RFC 8747はappropriateにprotectされるsymmetric proof-of-possession keyを認めます.

Q6: backendがこれをend-to-end proof of possessionと呼ぶ前に何を要求すべきか

Multiple Choice

A2A agentはgateway nonceをsignしてCWT cnf keyのpossessionを証明します.gatewayは別requestでCWTとboolean pop_ok=trueをbackendへforwardします.backend policyはbackend operationへbindされたcurrent proofを要求し,gateway exchangeのreplayをrejectします.

**Explanation:** A: Section 4はcurrent/replay-resistant proofを要求し,protocolがproof keyをparticipating partiesへlinkすると述べます.new hopはcontextを変えます. B: cnf claimはkeyをidentifyしますが,このrequestのbackend challengeやproofを含みません. C: Sections 3.5 and 4はproof protocolをapplicationへ委ねます.trust boundaryとprotected assertion semanticsが明示されればどちらも判定基準を満たせます. D: RFC 8747はnonce communication,signed-nonce transport,universal party-binding methodを意図的に定義しません.