Re: [GNAP] New I-D: draft-pinkas-gnap-core-protocol

[Denis <[e-mail]>]

Hi Justin,

There is a difference between the following two sentences :

         All *requests *have to be over TLS or equivalent as per [BCP195 
<https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-06.html#BCP195>]. 

        (from : draft-ietf-gnap-core-protocol-06 on *page 105*)

Which "requests" ? Access token requests ? Requests from which entity to 
which other entity ?

and

       The protocol uses HTTPS for all *communications *between the 
client and the AS, as well as between the client and the RS.
       (from: draft-pinkas-gnap-core-protocol-00 on *page 1*).


IMO, the first one is ambiguous  while the second one is crystal clear.

As I wrote, nowhere in draft-ietf-gnap-core-protocol-06, the text is 
taking advantage of the security properties obtained thanks to the use 
of HTTPS.

Nevertheless, there are many other major issues raised about 
draft-ietf-gnap-core-protocol-06, that 
draft-pinkas-gnap-core-protocol-00 attempts
to address and to solve.

The very first version of draft-pinkas-gnap-core-protocol has been 
written from scratch with a Trust Relationships section (1.5) and both
a Security Considerations section (4) and a Privacy Considerations 
section (5). Writing these three sections in a very first version is a
good way to have a document understandable and coherent.

Denis

> I want to clarify one point of confusion here:
>
>> The charter of the GNAP WG states, close to its end :
>>
>>
>>            "The initial work will focus on using HTTPS for 
>> communication between the client and the authorization server, (...)"
>>
>>            See: https://datatracker.ietf.org/doc/charter-ietf-gnap/
>>
>> Unfortunately, draft-ietf-gnap-core-protocol-06 does not mandate the 
>> use of HTTPS for communication between the client and the 
>> authorization server
>> and does not take advantage of the security properties obtained 
>> thanks to the use of HTTPS. This means that 
>> draft-ietf-gnap-core-protocol-06
>> does not comply with the GNAP charter.
>>
> This was quoted out of context and misrepresents the goal. If you read 
> the rest of that sentence, you’ll see that it’s talking about HTTP 
> versions:
>
>     The initial work will focus on using HTTPS for communication between the client
>     and the authorization server, taking advantage of optimization features of
>     HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to
>     other protocols such as CoAP when doing so does not conflict with the primary
>     focus.
>
> What this is saying is that we shouldn’t make something that is only 
> deployable on HTTP/1.
>
> Additionally, the GNAP core draft does already require HTTPS. While 
> the security considerations section (section 12) is not yet filled out 
> (though note — this one of the topics the editors are actively working 
> on), the one item it does have in there mandates HTTPS:
>
> All requests have to be over TLS or equivalent as per [BCP195 
> <https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-06.html#BCP195>].
>
>
> Therefore, the statement as asserted in this email, and the 
> conclusions that follow it, are not accurate.
>
>  — Justin