Draft: draft-ietf-gnap-core-protocol

Commentary: Please take a look at this updated text to see if it addresses your concerns . 
 To edit notification comments on pull requests , go to your . 
 Thinking about possible extensions to  's interaction modes , I had the impression that the specification could be a bit clearer regarding requirements on such extensions . From reading Section 3.3 , my understanding is that all implementations of GNAP , including ones using extensions which define additional interaction finish methods , MUST include a nonce in the grant response ( given that the AS wants to use the finish method offered by the client instance ): However , Section 3.3.5 sounds a bit different , only referring to the two interaction finish methods defined by GNAP core : Section 4.2 could be a bit clearer as to what is expected of future extensions to GNAP , it currently says : with the two following sections describing the finish methods defined by GNAP core . This is , however , somewhat clearer in Section 4.2.3 : I.e. , Section 4.2.3 implies that AS must ( somehow ) provide the client instance with an interaction reference and interaction finish nonce . But it may be helpful to make this more explicit throughout the relevant Sections . There seem to be no requirements for future interaction start methods . It may be helpful to document some minimal requirements , e.g. , enough information to identify the grant has to be conveyed to AS via RO in the interaction start ( such as the redirect URI in GNAP core ) . 
 Thanks for taking the time ! The proposed text looks good to me ( just one possible typo , I 'm not a native speaker , so I 'm not 100 % sure about that ) .
Paragraph (version B):
All interaction start method definitions MUST provide enough
information to uniquely identify the grant request during the
interaction.  In the "redirect" and "app" modes, this is done using a
unique URI (including its parameters).  In the "user_code" and
"user_code_uri" mode, this is done using the value of the user code.
Paragraph (version A):
If interaction finishing is supported for this client instance and
request, the AS response-interact-finish used by the client instance
to validate the callback.  Requests to the callback URI MUST be
processed as described in interaction-finish, and the AS MUST require
presentation of an interaction callback reference as described in
continue-after-interaction.
Paragraph (version B):
If interaction finishing is supported for this client instance and
request, the AS will response-interact-finish used by the client
instance to validate the callback.  All interaction finish methods
MUST use this nonce to allow the client to verify the connection
between the pending interaction request and the callback.  GNAP does
this through the use of the interaction hash, defined in interaction-
hash.  All requests to the callback URI MUST be processed as
described in interaction-finish.
Paragraph (version B):
All interaction finish methods MUST require presentation of an
interaction reference for continuing this grant request.  This means
that the the interaction reference MUST be returned by the AS and
MUST be presented by the client as described in continue-after-
interaction.  The means by which the interaction reference is
returned to the client instance is specific to the interaction finish
method.
Paragraph (version A):
The AS MUST send the hash and interaction reference based on the
interaction finish mode as described in the following sections.
Paragraph (version B):
All interaction finish methods MUST define a way to convey the hash
and interaction reference back to the client instance.  When an
interaction finish method is used, the client instance MUST present
the interaction reference back to the AS as part of its continue-
after-interaction.