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

[Rifaat Shekh-Yusef]

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