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

[Omri Gazitt]

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.


>
> 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/20240304/9a8cbd0f/attachment.html>