jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-ace-oauth-authz

Commentary: I removed the part about the DoS via AS Discovery hints since it was unrealistic . 
 I changed the text . Text . Text . Here is the text from Section 7.2 of draft - ietf - ace - dtls - authorize : All editorial comments addressed . 
 PR addressing comments can be found here : 
 Merged
Developers MUST ensure that the ephemeral credentials (i.e., the
private key or the session key) are not leaked to third parties.  An
adversary in possession of the ephemeral credentials bound to the
access token will be able to impersonate the client.  Be aware that
this is a real risk with many constrained environments, since
adversaries can often easily get physical access to the devices and
therefore use phyical extraction techniques to gain access to memory
contents.  This risk can also be mitigated to some extent by making
sure that keys are refreshed more frequently.
Care must by taken by developers to prevent leakage of the PoP
credentials (i.e., the private key or the symmetric key).  An
adversary in possession of the PoP credentials bound to the access
token will be able to impersonate the client.  Be aware that this is
a real risk with many constrained environments, since adversaries may
get physical access to the devices and can therefore use phyical
extraction techniques to gain access to memory contents.  This risk
can be mitigated to some extent by making sure that keys are
refreshed frequently, by using software isolation techniques and by
using hardware security.
Draft: draft-ietf-ace-oauth-authz

Commentary: Nits addressed . 
 Partially addressed by PR 
 Merged
The "scope" parameter MAY be encoded as a byte string instead of
the string encoding specified in section 3.3 of RFC6749, in order
allow compact encoding of complex scopes.  The syntax of such a
binary encoding is explicitly not specified here and left to
profiles or applications, specifically note that a binary encoded
scope does not necessarily use the space character '0x20' to
delimit scope-tokens.
The "scope" parameter MAY be encoded as a byte string instead of
the string encoding specified in section 3.3 of RFC6749, in order
allow compact encoding of complex scopes.  The syntax of such a
binary encoding is explicitly not specified here and left to
profiles or applications.  Note specifically that a binary encoded
scope does not necessarily use the space character '0x20' to
delimit scope-tokens.
Draft: draft-ietf-ace-oauth-authz

Commentary: Fixed . Changed . 
 The review comments are addressed by 
 Fixed
Token introspection RFC7662 can be OPTIONALLY provided by the AS, and
is then used by the RS and potentially the client to query the AS for
metadata about a given token, e.g., validity or scope.  Analogous to
the protocol defined in RFC7662 for HTTP and JSON, this section
defines adaptations to more constrained environments using CBOR and
leaving the choice of the application protocol to the profile.
Token introspection RFC7662 MAY be implemented by the AS, and the RS.
When implemented, it MAY be used by the RS and to query the AS for
metadata about a given token, e.g., validity or scope.  Analogous to
the protocol defined in RFC7662 for HTTP and JSON, this section
defines adaptations to more constrained environments using CBOR and
leaving the choice of the application protocol to the profile.
Communication between the requesting entity and the introspection
endpoint at the AS MUST be integrity protected and encrypted.  The
communication security protocol MUST also provide a binding between
requests and responses.  Furthermore the two interacting parties MUST
perform mutual authentication.  Finally the AS SHOULD verify that the
requesting entity has the right to access introspection information
about the provided token.  Profiles of this framework that support
introspection MUST specify how authentication and communication
security between the requesting entity and the AS is implemented.
The default name of this endpoint in an url-path is '/introspect',
however implementations are not required to use this name and can
define their own instead.
The figures of this section uses CBOR diagnostic notation without the
integer abbreviations for the parameters or their values for better
readability.
Note that supporting introspection is OPTIONAL for implementations of
this framework.
Communication between the requesting entity and the introspection
endpoint at the AS MUST be integrity protected and encrypted.  The
communication security protocol MUST also provide a binding between
requests and responses.  Furthermore, the two interacting parties
MUST perform mutual authentication.  Finally, the AS SHOULD verify
that the requesting entity has the right to access introspection
information about the provided token.  Profiles of this framework
that support introspection MUST specify how authentication and
communication security between the requesting entity and the AS is
implemented.
The default name of this endpoint in an url-path SHOULD be
'/introspect'.  However, implementations are not required to use this
name and can define their own instead.
The figures of this section use the CBOR diagnostic notation without
the integer abbreviations for the parameters and their values for
better readability.
Draft: draft-ietf-ace-oauth-authz

Commentary:  wrote : 
 Addressed by this PR : 
 Merged
More detailed, interoperable specifications can be found in separate
profile specifications, which specify different deployment options of
this framework (e.g. with respect to communication security).
Implementations may claim conformance with a specific profile,
whereby implementations utilizing the same profile interoperate,
while implementations of different profiles are not expected to be
interoperable.  Some devices, such as mobile phones and tablets, may
implement multiple profiles and will therefore be able to interact
with a wider range of low end devices.  Requirements on profiles are
described at contextually appropriate places throughout this
specification, and also summarized in app:profileRequirements.
Profiles of this framework are available in separate specifications,
such as I-D.ietf-ace-dtls-authorize or I-D.ietf-ace-oscore-profile.
Such profiles may specify the use of the framework for a specific
security protocol and the underlying transports for use in a specific
deployment environment to improve interoperability.  Implementations
may claim conformance with a specific profile, whereby
implementations utilizing the same profile interoperate, while
implementations of different profiles are not expected to be
interoperable.  More powerful devices, such as mobile phones and
tablets, may implement multiple profiles and will therefore be able
to interact with a wider range of constrained devices.  Requirements
on profiles are described at contextually appropriate places
throughout this specification, and also summarized in
app:profileRequirements.
Draft: draft-ietf-ace-oauth-authz

Commentary: Feedback from implementers : Section 5.10.1 of the ACE framework uses the term " overwrite " " 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 reason is that this greatly simplifies ( constrained ) implementations , with respect to required storage and resolving a request to the applicable token . " and this is mirrored in the OSCORE profile . However , this is not strictly an overwrite of a token because some information in the original token needs to be kept . For example , if the client requests new access rights only using the kid as reference , and the corresponding access token overwrites the original token , then information about the actual key would be lost . Proposed reformulation : " This specification RECOMMENDS that an RS stores only one token per proof - of - possession key . This means that an additional token linked to the same key will supersede any existing token at the RS , by replacing the corresponding authorization information . The reason is that ... "
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 reason
is that this greatly simplifies (constrained) implementations, with
respect to required storage and resolving a request to the applicable
token.
This specification RECOMMENDS that an RS stores only one token per
proof-of-possession key.  This means that an additional token linked
to the same key will supersede any existing token at the RS, by
replacing the corresponding authorization information.  The reason is
that this greatly simplifies (constrained) implementations, with
respect to required storage and resolving a request to the applicable
token.
Draft: draft-ietf-ace-oauth-authz

Commentary: Looks good to me .
This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments.  The
framework is based on a set of building blocks including OAuth 2.0
and CoAP, thus making a well-known and widely used authorization
solution suitable for IoT devices.  Existing specifications are used
where possible, but where the constraints of IoT devices require it,
extensions are added and profiles are defined.
This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE-
OAuth.  The framework is based on a set of building blocks including
OAuth 2.0 and CoAP, thus making a well-known and widely used
authorization solution suitable for IoT devices.  Existing
specifications are used where possible, but where the constraints of
IoT devices require it, extensions are added and profiles are
defined.
Draft: draft-ietf-ace-oauth-authz

Commentary: Looks good . Thanks for correcting the nits as well .
The client sends a POST request to the token endpoint at the AS.  The
profile MUST specify the Content-Type and wrapping of the payload.
The content of the request consists of the parameters specified in
Section 4 of the OAuth 2.0 specification RFC6749, encoded as a CBOR
map (if a CBOR encoding is used), where the "scope" parameter can
additionally be formatted as a byte array, in order to allow compact
encoding of complex scope structures.
The client sends a POST request to the token endpoint at the AS.  The
profile MUST specify the Content-Type and wrapping of the payload.
The content of the request consists of the parameters specified in
Section 4 of the OAuth 2.0 specification RFC6749.
If CBOR is used then this parameter is encoded as a CBOR map, where
the "scope" parameter can additionally be formatted as a byte array,
in order to allow compact encoding of complex scope structures.
When HTTP is used as a transport then the client makes a request to
the token endpoint by sending the parameters using the "application/
x-www-form-urlencoded" format with a character encoding of UTF-8 in
the HTTP request entity-body, as defined in RFC 6749.
This parameter specifies for which audience the client is requesting
a token.  If using CBOR payload it should be encoded as CBOR text
string.  The formatting and semantics of these strings are
application specific.
This parameter specifies for which audience the client is requesting
a token.  The formatting and semantics of these strings are
application specific.
When encoded as a CBOR payload it is represented as a CBOR text
string.
The "cnf" parameter identifies or provides the key used for proof-of-
possession, while the "rs_cnf" parameter provides the raw public key
of the RS.  Both parameters use the same formatting and semantics as
the "cnf" claim specified in I-D.ietf-ace-cwt-proof-of-possession.
The "cnf" parameter identifies or provides the key used for proof-of-
possession, while the "rs_cnf" parameter provides the raw public key
of the RS.  Both parameters use the same formatting and semantics as
the "cnf" claim specified in I-D.ietf-ace-cwt-proof-of-possession
when used with a CBOR encoding.  When these parameters are used in
JSON then the formatting and semantics of the "cnf" claim specified
in RFC 7800 RFC7800.