Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Ludwig Seitz <[e-mail]>]

On 28/10/2019 22:06, Benjamin Kaduk wrote:

>>> 32.)
>>> Section 5.6.1
>>>
>>>     The client sends a POST request to the token endpoint at the AS.  The
>>>     profile MUST specify how the communication is protected.  The content
>>>
>>> In the previous section we said that maybe even other transports than
>>> coaps or https would be possible; are we limited to those that have POST
>>> verbs?
>>> Also, a similar comment as above about what attributes the protection
>>> entails seems to apply.
>>
>> [LS] This will need a major rephrasing of the text.
>> I see two options here:
>>
>> 1.) We rewrite all parts to use a neutral language in general and specify
>> POST/GET etc. for transports that have these verbs.
>>
>> 2.) We state in the beginning that transports that do not use RESTful verbs
>> should use the best equivalent.
>>
>> Option 1. would get a bit cluncky, while option 2. might be a bit confusing
>> Do you have a specific preference?
>>
>> [JLS] I would suggest that this could fall under the punt to the new transport that does not have the same as these verbs in it to explain how they would map.
> 
> I agree that (1) is more effort than it's likely to be worth.  If we can
> finagle a single-sentence disclaimer like "transports that do not use these
> verbs will need to specify the requisite behavior" that would be great; if
> not, then we can consider whether to just ignore it or do something more
> complicated.

I'll go for this:

" Note that this document specifies
   protocol exchanges in terms of RESTful commands such as GET and POST.
   Future profiles using protocols that do not support these verbs MUST
   specify how the corresponding protocol messages are transmitted instead.
"

In the Overview section where we mention alternate transport protocols.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]