<div dir="ltr">Omri,<div><br></div><div>Thanks for the demo during today's call and the clarification that the TODO list is a <b>shared list</b>.</div><div>It would be good to explicitly state that in the document to avoid any future confusion.</div><div><br></div><div>Regards,</div><div> Rifaat</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2024 at 12:42 PM Rifaat Shekh-Yusef <<a href="mailto:rifaat.s.ietf@gmail.com">rifaat.s.ietf@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2024 at 2:14 AM Omri Gazitt <<a href="mailto:omri@aserto.com" target="_blank">omri@aserto.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Thanks for the comments Rifaat, answers inline.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 28, 2024 at 5:53 AM Rifaat Shekh-Yusef via Openid-specs-authzen <<a href="mailto:openid-specs-authzen@lists.openid.net" target="_blank">openid-specs-authzen@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">All,<div><br></div><div>I have reviewed the "Payloads for the Todo application interop scenario" document:</div><div><a href="https://hackmd.io/gNZBRoTfRgWh_PNM0y2wDA" target="_blank">https://hackmd.io/gNZBRoTfRgWh_PNM0y2wDA</a></div><div><br></div><div>and I have the following comments:<br></div><div><br></div><div><br></div><div><b>GET /users/{userID}<br></b><br>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.<br><br>Why do you need both: the userID in request URI and the PID in the payload?<br></div></div></blockquote><div><br></div><div>There are three moving parts here:</div><div>* React frontend, which expects a backend that serves these 5 routes</div><div>* Node.js backend API, which serves the 5 routes</div><div>* AuthZEN implementation, which authorizes each request</div><div><br></div><div>The Todo app (React frontend) calls the <b>GET /users/{userID} </b>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.</div><div><br></div><div>The Todo backend calls an AuthZEN implementation with the payload that's provided in the document. Note that the <b>subject.identity</b> field contains the PID <i>of the caller</i> (i.e. the user that is logged in, e.g. Rick or Morty), whereas the <b>resource.userID </b>field contains the <b>userID </b>from the route.</div></div></div></blockquote><div><br></div><div>Can you please elaborate on this? How are these users different?<br></div><div><br></div><div>Regards,</div><div> Rifaat</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>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?<br></div></div></blockquote><div><br></div><div>They are just names that make it clear that there are no "reserved verbs" here. The authorizer implementation has <b>no idea</b> 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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>What is the reason for adding “userId” in the payload under “resource”?<br><br></div></div></blockquote><div><br></div><div>This is the resource that is being authorized. For simplicity, when describing the authorization policy, we specified that the <b>GET /users/{userID} </b>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br><b>GET /todos</b><br><br>The previous GET request included a userID in the request URI.<br>Why is this not included in this request?<br><br></div></div></blockquote><div><br></div><div>This route returns all the Todos.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br><b>POST /todos</b><br><br>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?<br></div></div></blockquote><div><br></div><div>This route creates a new todo, and stores the currently logged-in user as the owner of the Todo.</div><div><br></div><div>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}.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br><br><b>PUT /todos/{id}</b><br><br>I am assuming that the {id} in the request URI above is the todo id? Is that the case?<br></div></div></blockquote><div><br></div><div>Yes</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I am not clear on the role of the ownerID; can you please elaborate on this?<br></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>Regards,</div><div> Rifaat</div><div><br></div><div><br></div><div><br></div></div>
-- <br>
Openid-specs-authzen mailing list<br>
<a href="mailto:Openid-specs-authzen@lists.openid.net" target="_blank">Openid-specs-authzen@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div>