[Openid-specs-authzen] Review of "Payloads for the Todo application interop scenario"

[Rifaat Shekh-Yusef]

Omri,

Thanks for the demo during today's call and the clarification that the TODO
list is a *shared list*.
It would be good to explicitly state that in the document to avoid any
future confusion.

Regards,
 Rifaat



On Tue, Mar 5, 2024 at 12:42 PM Rifaat Shekh-Yusef <rifaat.s.ietf at gmail.com>
wrote:

>
>
> On Tue, Mar 5, 2024 at 2:14 AM Omri Gazitt <omri at aserto.com> wrote:
>
>> Thanks for the comments Rifaat, answers inline.
>>
>> On Wed, Feb 28, 2024 at 5:53 AM Rifaat Shekh-Yusef via
>> Openid-specs-authzen <openid-specs-authzen at lists.openid.net> wrote:
>>
>>> All,
>>>
>>> I have reviewed the "Payloads for the Todo application interop scenario"
>>> document:
>>> https://hackmd.io/gNZBRoTfRgWh_PNM0y2wDA
>>>
>>> and I have the following comments:
>>>
>>>
>>>
>>> *GET /users/{userID}*
>>> This seems to be a REST request that attempts to access information
>>> about a user that is identified in the request URI with a userID, which is
>>> the email address of the user. The payload includes an “identity” field
>>> which contains the PID, which contains all the information about the user,
>>> including the userID.
>>>
>>> Why do you need both: the userID in request URI and the PID in the
>>> payload?
>>>
>>
>> There are three moving parts here:
>> * React frontend, which expects a backend that serves these 5 routes
>> * Node.js backend API, which serves the 5 routes
>> * AuthZEN implementation, which authorizes each request
>>
>> The Todo app (React frontend) calls the *GET /users/{userID} *route to
>> get back information about a user based on their userID. It uses this
>> information to render a picture of the owner of each Todo.
>>
>> The Todo backend calls an AuthZEN implementation with the payload that's
>> provided in the document. Note that the *subject.identity* field
>> contains the PID *of the caller* (i.e. the user that is logged in, e.g.
>> Rick or Morty), whereas the *resource.userID *field contains the *userID
>> *from the route.
>>
>
> Can you please elaborate on this? How are these users different?
>
> Regards,
>  Rifaat
>
>
>
>
>
>>
>>
>>>
>>> What is the reason for the elaborate action name “can_read_user”? Isn't
>>> that clear already from the fact that it is a GET request on the
>>> /users/{userID} resource? Would it not be sufficient to use “read” as a
>>> value?
>>>
>>
>> They are just names that make it clear that there are no "reserved verbs"
>> here. The authorizer implementation has *no idea* what the route is that
>> is being called on the backend API.  We agreed in last week's call that
>> rather than structure the action as { "method": "GET", "path":
>> "/users/{userID}" }  as I first suggested, we would use generic names.
>> There are 5 permissions defined, one for each operation.  We chose
>> descriptive names.
>>
>>
>>>
>>> What is the reason for adding “userId” in the payload under “resource”?
>>>
>>>
>> This is the resource that is being authorized. For simplicity, when
>> describing the authorization policy, we specified that the *GET
>> /users/{userID} *route should return a "true" decision value for every
>> combination of user and userID. So it is actually doesn't matter if you
>> omit it from the resource of the payload - the policy should allow the
>> operation regardless.
>>
>>
>>>
>>> *GET /todos*
>>>
>>> The previous GET request included a userID in the request URI.
>>> Why is this not included in this request?
>>>
>>>
>> This route returns all the Todos.
>>
>>
>>>
>>> *POST /todos*
>>>
>>> I am assuming you need an ID that is associated with a specific todo? If
>>> this is the case, then should not the response include that todo id, so you
>>> are able to refer to it in subsequent interactions?
>>>
>>
>> This route creates a new todo, and stores the currently logged-in user as
>> the owner of the Todo.
>>
>> The contract between the front-end and the backend is that the front-end
>> loads all the todos (using the GET /todos route) and if a user edits or
>> deletes a Todo, the React app uses the {id} field found in the Todo as part
>> of the PUT or DELETE /todos/{id}.
>>
>>
>>>
>>>
>>> *PUT /todos/{id}*
>>>
>>> I am assuming that the {id} in the request URI above is the todo id? Is
>>> that the case?
>>>
>>
>> Yes
>>
>>
>>> I am not clear on the role of the ownerID; can you please elaborate on
>>> this?
>>>
>>
>> The policy we agreed upon in a previous meeting (again, very simple) is
>> that an owner of a Todo can complete (edit) it or delete it. In addition, a
>> user with the role "admin" can delete any Todo, while a user with the role
>> "evil_genius" can edit any Todo.
>>
>>
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>>
>>> --
>>> Openid-specs-authzen mailing list
>>> Openid-specs-authzen at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240305/44feef48/attachment.html>