ToppyMicroServices

RFC 8392 Quiz (EN)

CBOR Web Token (CWT)

ENJA
0 / 0

Primary reference

These questions separate CBOR representation, COSE processing, claim validation, creator trust, and downstream authorization. Section numbers refer to RFC 8392.

Q1: Which statement correctly divides responsibility between RFC 8392 and an A2A CWT profile?

Multiple Choice

A constrained A2A profile wants compact authorization claims and plans to use CWTs protected by COSE.

A: Section 3 says the registered claims are not mandatory as a set; applications define which claims are used and whether they are required. B: Sections 7.1 and 7.2 cover signed, MACed, and encrypted CWTs, and the CWT Claims Set is a CBOR map. C: Sections 3 and 7 define that boundary: interoperable representation and protection processing come from the RFC, while the application supplies its claim profile. D: RFC 8392 specifies the CBOR claims set and invokes COSE processing; those are not left undefined.

Q2: Must this receiver reject the untagged CWT?

Multiple Choice

An A2A message schema says that field 4 contains a CWT. The field contains an untagged COSE_Sign1 object, and the receiver knows its type from that schema position.

A: Section 6 makes the CWT tag optional and describes application context and media type as other ways to identify a CWT. B: This follows Section 6. If tag 61 is present, it prefixes a tagged COSE object; its absence does not bypass Section 7.2 validation. C: Identification and cryptographic validation are separate. An untagged COSE object still undergoes the applicable COSE validation. D: Section 6 lists application/cwt as one method, not a mandatory in-message field.

Q3: May the resource server authorize after only the RFC 8392 Section 7.2 steps?

Multiple Choice

The CWT is a valid CBOR map and its COSE_Sign1 signature verifies. The A2A profile requires aud to identify this resource and exp to be current, but the validator has not examined either claim. Authorization requires both profile conditions.

A: Section 7.2 validates the CBOR and COSE construction; it does not choose the claim set or the operation's authorization policy. B: Section 8 distinguishes authenticating the CWT creator from deciding whether the claims are acceptable for an operation. C: Section 3 permits applications to require and process registered claims; being profile-defined does not make those claims invalid. D: Sections 3 and 7.2 provide the two stages. Sections 3.1.3 and 3.1.4 import the aud and exp processing semantics, while this profile makes them required.

Q4: How should the second implementation handle claim 500?

Multiple Choice

An A2A profile defines private claim 500 as the required operation class and says requests without a recognized value are rejected. One implementation understands it; another applies the generic unknown-claim rule and ignores it. Interoperable authorization is the decision criterion.

A: Section 3 says unknown claims are ignored in the absence of application requirements and also says applications define claims that must be understood and processed. This profile supplies such a requirement. B: That reading omits the qualifying context in Section 3 and would defeat the profile's stated authorization rule. C: Claim keys identify defined semantics; unilateral remapping creates a different, non-interoperable profile. D: Logging does not satisfy the profile's pre-authorization decision criterion.

Q5: What can the verifier conclude about the claimed issuer?

Multiple Choice

Five devices share the same symmetric COSE MAC key. A MACed CWT says iss=device-A, and its MAC verifies. The authorization rule requires evidence that device-A, rather than another group member, created the claims.

A: Integrity protects the iss value from outsiders, but every holder of the group MAC key can create an equally valid value. B: Section 8 requires the recipient to authenticate the party that assembled the claims and to trust that party. A shared group key does not meet the scenario's per-device origin criterion by itself. C: Section 3.1.7 defines cti as a token identifier; it is not proof of which group member generated the token. D: Section 6 uses tag 61 to identify the object as a CWT, not to identify its creator.

Q6: Can the backend treat the forwarded claims as the original CWT evidence?

Multiple Choice

An A2A gateway validates a CWT, checks aud=gateway, and forwards plain JSON containing sub and operation to a resource-owning backend. The backend receives the JSON over an authenticated gateway connection but neither the CWT nor a gateway assertion covering audience, issuer, and validation time. Backend policy requires evidence intended for this backend operation.

A: Sections 7.2 and 8 protect and authenticate the CWT at its verifier; selected plaintext fields do not retain that protection automatically. B: Section 3 leaves required-claim and audience use to the application profile. The stated backend criterion is not met merely by aud=gateway. C: This separates RFC processing from composition policy. The gateway can be an explicit new trust boundary, but its assertion must carry the semantics and protection on which the backend relies. D: RFC 8392 defines CWT processing and does not prohibit a trusted gateway architecture; the profile must define the resulting trust and authorization boundaries.

Q7: May the issuer keep the epoch-date tag on this exp value?

Multiple Choice

A generic CBOR library encodes the exp claim as CBOR tag 1 applied to an epoch number. The CWT profile needs the standard RFC 8392 exp claim, not a newly defined claim.

A: Section 5 says the claims defined by RFC 8392 MUST NOT have CBOR tags prefixed to their values. B: exp already has the integer-or-floating-point NumericDate representation, so the extra tag adds no information. C: The outer CWT tag and a claim-value tag are independent. D: Sections 2 and 4 allow either an integer or floating-point number for exp. A future claim definition may require a tag, but this standard exp claim does not.

Q8: How should the validator handle this cti representation?

Multiple Choice

A producer encodes claim key 7 as the CBOR text string "token-123". The receiver expects the registered cti claim and uses it for replay-state lookup.

A: StringOrURI applies to claims such as iss and sub, not cti. B: Post-lookup coercion lets different encodings reach the security state before validation. C: Claim key 7 is registered for cti and cannot be silently remapped. D: Section 3.1.7 and Table 1 define cti as a byte string. The application may define how those bytes map to its replay database, but it should validate the registered representation first.

Q9: Is outer decryption sufficient for this nested CWT?

Multiple Choice

A recipient successfully decrypts a COSE_Encrypt0 CWT. The plaintext begins with a COSE_Sign1 tag, but the implementation parses its payload as claims and authorizes without validating the inner signature.

A: RFC 8392 Section 7.2 Step 6 says that when the resulting Message begins with a COSE CBOR tag, it is a nested CWT and validation returns to Step 1 using that Message. B: Decryption and signature verification provide different properties. C: Section 7.2 explicitly recurses through nested operations. D: Nested CWTs are supported; skipping an inner validation step is the defect.

Q10: How should the profile state its signing-and-encryption order?

Multiple Choice

An A2A profile needs both signer privacy and protection against stripping a signature from a nested CWT. Its editor claims RFC 8392 universally mandates one nesting order.

A: Section 8 says nested operations are syntactically possible in any order; it does not make encrypt-then-sign the only valid syntax. B: Section 8 normally recommends signing and then encrypting. C: That order hides the signature and helps prevent signature stripping, matching the stated goals; making it mandatory is the profile's decision. D: The RFC explains why the security and privacy properties differ. The recommendation is not a universal RFC MUST.