Hi Olaf,
On 9/17/20 4:09 AM, Olaf Bergmann wrote:
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.
[...]
Sorry to be so dense, but I'm still not getting it.
I take your point that this is only an example of a way to agree on a
shared secret. But at the end of the day they indeed must somehow agree
on a shared secret. *If* they use this technique then it will only work
if they also agree on a consistent way to do the serialization and
encoding that is otherwise not standardized. So they need a side
agreement, which is not a good situation for a standardized protocol.
At the very least it seems like you should highlight that some sort of
out of band communication is required between the authorization and
resource servers to establish the shared secret or the algorithm to be
used for deriving the shared secret.
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.
That seems ok.
Thanks,
Paul
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
