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

[Omri Gazitt]

Thanks for the feedback Rifaat.

I made some updates in the front-matter of the document. Hopefully it is
more self-contained and doesn't require as much context from previous
meetings now...

Thanks,
Omri.


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

> 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/b4d6eee6/attachment-0001.html>