Hi Paul, Responding to you remaining comments please see inline.
Paul Kyzivat <pkyzi...@alum.mit.edu> writes: >>>> * Also in section 3.3: >>>> >>>> All CBOR data types are encoded in CBOR using preferred serialization >>>> and deterministic encoding as specified in Section 4 of >>>> [I-D.ietf-cbor-7049bis]. This implies in particular that the "type" >>>> and "L" components use the minimum length encoding. The content of >>>> the "access_token" field is treated as opaque data for the purpose of >>>> key derivation. >>>> >>>> IIUC the type of serialization and encoding is a requirement. Will >>>> need some rewording to make it so. >>> >>> I take it that you and Ben have agreed that the example description does >>> not necessarily need normative language as the description of this key >>> derivation procedure is meant as an example how the authorization server >>> and the resource server can securely agree on a shared secret to be used >>> between the client and the resource server. > > This still confuses me. IIUC preferred serialization and deterministic > encoding are *optional* in CBOR. The text hear seems to require it, > but doesn't use normative language to do so. > > If these are required for things to work then you make a normative > statement about it. E.g., "The "type" and "L" components MUST use the > minimum length encoding." > > Or do you intend that some other (non-minimum-length) MAY be used? (In > which case both sides would need a side agreement on what encoding is > used.) The text here just gives an example how key derivation may be used by the authorization server and the resource server to agree on a shared secret (that is used to encrypt the traffic between the resource server and the to-be-authorized client). To that regard, the text is not really normative. The only normative language we need here would be to avoid security issues. Commenting on the data representation here is to be understood as a suggestion to use, e.g., preferred CBOR serialization according to 7049bis. [...] >>> OLD: >>> >>> New access tokens issued by the authorization server are supposed to >>> replace previously issued access tokens for the respective client. >>> >>> NEW: >>> >>> New access tokens issued by the authorization server replace >>> previously issued access tokens for the respective client. > > The above is still non-normative. Perhaps: > > New access tokens issued by the authorization server MUST replace > previously issued access tokens for the respective client. Following Section 5.8.1 of the framework document, this should be a SHOULD (the text there reads as: "This specification RECOMMENDS that an RS stores only one token per proof-of-possession key, meaning that an additional token linked to the same key will overwrite any existing token at the RS." The text then would read as follows (changes are the new SHOULD and "needs a common understanding" instead of "must have": OLD: According to Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one access token for each client. New access tokens issued by the authorization server replace previously issued access tokens for the respective client. The resource server therefore must have a common understanding with the authorization server how access tokens are ordered. The authorization server may, e.g., specify a "cti" claim for the access token (see Section 5.8.3 of [I-D.ietf-ace-oauth-authz]) to employ a strict order. NEW: According to Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one access token for each client. New access tokens issued by the authorization server SHOULD replace previously issued access tokens for the respective client. The resource server therefore needs a common understanding with the authorization server how access tokens are ordered. The authorization server may, e.g., specify a "cti" claim for the access token (see Section 5.8.3 of [I-D.ietf-ace-oauth-authz]) to employ a strict order. Grüße Olaf _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
