ToppyMicroServices

RFC 8392 Quiz (JA)

CBOR Web Token (CWT)

ENJA
0 / 0

一次資料

CBOR representation、COSE processing、claim validation、creator trust、downstream authorizationを分けて扱います。Section番号はRFC 8392を指します。

Q1: RFC 8392とA2A CWT profileの責務を正しく分けた説明はどれか

Multiple Choice

constrainedなA2A profileがcompactなauthorization claimを必要とし,COSEで保護したCWTを使う予定です.

A: Section 3はregistered claim一式をmandatoryにしていません.applicationが使用するclaimとrequiredかどうかを定義します. B: Sections 7.1 and 7.2はsigned,MACed,encrypted CWTを扱い,CWT Claims SetはCBOR mapです. C: Sections 3 and 7がこの境界を定義します.interoperableな表現・保護処理はRFCから,claim profileはapplicationから得ます. D: RFC 8392はCBOR claims setとCOSE処理を規定しており,それらを未定義のままprofileへ委ねません.

Q2: receiverはこのuntagged CWTを拒否しなければならないか

Multiple Choice

A2A message schemaはfield 4にCWTを置くと定義しています.fieldにはuntagged COSE_Sign1 objectがあり,receiverはschema上の位置からtypeを認識できます.

A: Section 6はCWT tagをoptionalとし,application contextやmedia typeもCWTを識別する方法として説明します. B: Section 6に沿う処理です.tag 61がある場合はtagged COSE objectをprefixしますが,tagがなくてもSection 7.2の検証は省略しません. C: objectの識別とcryptographic validationは別です.untagged COSE objectにも該当するCOSE検証を行います. D: Section 6はapplication/cwtを一つの方法として示しますが,message内のmandatory fieldにはしていません.

Q3: resource serverはRFC 8392 Section 7.2の手順だけでauthorizeしてよいか

Multiple Choice

CWTはvalidなCBOR mapで,COSE_Sign1 signatureも検証済みです.A2A profileはaudがこのresourceを示し,expが有効期間内であることを要求しますが,validatorはどちらも未確認です.authorizationには両条件が必要です.

A: Section 7.2はCBOR/COSE constructionを検証しますが,claim setやoperationのauthorization policyを選びません. B: Section 8はCWT creatorのauthenticationと,claimがoperationに受理可能かの判断を分けています. C: Section 3はapplicationがregistered claimをrequiredとして処理することを認めます.profile-definedであることはclaimをinvalidにしません. D: Sections 3 and 7.2の二段階を適用します.Sections 3.1.3 and 3.1.4がaud/exp semanticsを取り込み,このprofileがそれらをrequiredにしています.

Q4: 二つ目のimplementationはclaim 500をどう扱うべきか

Multiple Choice

A2A profileはprivate claim 500をrequiredなoperation classと定義し,値を認識できないrequestをrejectします.一方のimplementationは理解しますが,もう一方はgenericなunknown-claim ruleで無視します.interoperableなauthorizationが判定基準です.

A: Section 3はapplication requirementがない場合にunknown claimをignoreし,同時にapplicationが理解・処理すべきclaimを定義すると述べます.このprofileがそのrequirementを与えます. B: Section 3の条件を落とした読み方であり,profileが指定したauthorization ruleを無効にします. C: Claim keyは定義されたsemanticsを識別します.一方的なremappingは別の非互換profileを作ります. D: Loggingはpre-authorizationの判定基準を満たしません.

Q5: verifierはclaimed issuerについて何を結論できるか

Multiple Choice

5台のdeviceが同じsymmetric COSE MAC keyを共有しています.MACed CWTはiss=device-Aと主張し,MAC検証にも成功します.authorization ruleは他のgroup memberではなくdevice-Aがclaimを作成したevidenceを要求します.

A: Integrityは外部者によるiss変更を防ぎますが,group MAC keyを持つ全memberが同様にvalidな値を作れます. B: Section 8はrecipientがclaimsを組み立てたpartyをauthenticateし,そのpartyをtrustするよう求めます.shared group keyだけではscenarioのper-device origin条件を満たしません. C: Section 3.1.7のctiはtoken identifierであり,どのgroup memberが生成したかのproofではありません. D: Section 6のtag 61はobjectをCWTと識別するもので,creatorを識別しません.

Q6: backendはforwardされたclaimを元のCWT evidenceとして扱えるか

Multiple Choice

A2A gatewayがCWTを検証し,aud=gatewayを確認して,subとoperationを含むplain JSONだけをresource-owning backendへ転送します.backendはauthenticated gateway connectionでJSONを受け取りますが,CWTもaudience,issuer,validation timeを覆うgateway assertionも受け取りません.backend policyはこのbackend operation向けのevidenceを要求します.

A: Sections 7.2 and 8によるCWTの保護とorigin authenticationはverifierまでです.選択したplaintext fieldはその保護を自動継承しません. B: Section 3はrequired claimとaudienceの使い方をapplication profileへ委ねます.指定されたbackend criterionはaud=gatewayだけでは満たされません. C: RFC processingとcomposition policyを分離します.gatewayを明示的な新trust boundaryにできますが,assertionはbackendが依存するsemanticsとprotectionを持つ必要があります. D: RFC 8392はCWT processingを定義しますが,trusted gateway architectureを禁止しません.profileがtrustとauthorization boundaryを定義します.

Q7: issuerはこのexp valueへepoch-date tagを残してよいか？

単一選択

汎用CBOR libraryがexp claimをepoch numberへCBOR tag 1を付けてencodeする。CWT profileが必要なのは新規claimではなく、RFC 8392の標準exp claimである。

A: Section 5はRFC 8392が定義するclaim valueへCBOR tagをprefixしてはならないとします。B: expはintegerまたはfloating-point NumericDateとしてすでに表現が決まり、追加tagは情報を加えません。C: 外側のCWT tagとclaim-value tagは独立です。D: Sections 2と4はexpへintegerとfloating-point numberの両方を許します。将来のclaim定義はtagを要求できますが、この標準exp claimは要求しません。

Q8: validatorはこのcti representationをどう扱うべきか？

単一選択

producerはclaim key 7をCBOR text string "token-123"としてencodeする。receiverはregistered cti claimを想定し、replay-state lookupへ使う。

A: StringOrURIはissやsubなどへ適用され、ctiには適用されません。B: lookup後のcoercionでは、validation前に異なるencodingがsecurity stateへ到達します。C: Claim key 7はcti用に登録され、一方的にremapできません。D: Section 3.1.7とTable 1はctiをbyte stringと定義します。applicationはそのbyteをreplay databaseへmapする方法を定義できますが、まずregistered representationを検証します。

Q9: このnested CWTはouter decryptionだけで十分か？

単一選択

recipientはCOSE_Encrypt0 CWTのdecryptionに成功した。plaintextはCOSE_Sign1 tagで始まるが、実装はinner signatureを検証せず、そのpayloadをclaimsとしてauthorizeする。

A: RFC 8392 Section 7.2 Step 6は、得られたMessageがCOSE CBOR tagで始まる場合、それをnested CWTとしてMessageを使いStep 1へ戻るよう定めます。B: decryptionとsignature verificationは異なるpropertyを与えます。C: Section 7.2はnested operationを再帰的に検証します。D: nested CWTはsupportされており、問題はinner validationを飛ばしたことです。

Q10: profileはsigningとencryptionの順序をどう規定すべきか？

単一選択

A2A profileはsigner privacyと、nested CWTからsignatureをstripする攻撃への保護を必要とする。editorはRFC 8392が1つのnesting orderを一律にmandateすると主張する。

A: Section 8はnested operationをsyntax上どの順序でも可能とし、encrypt-then-signだけをvalidにしません。B: Section 8は通常signしてからencryptするよう勧めます。C: この順序はsignatureを隠し、signature strippingの防止に役立つため、指定された目的に合います。mandatoryにするのはprofileの判断です。D: RFCはsecurityとprivacy propertyが異なる理由を説明します。このrecommendationは一律のRFC MUSTではありません。