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

[Rifaat Shekh-Yusef]

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?

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?

What is the reason for adding “userId” in the payload under “resource”?


*GET /todos*

The previous GET request included a userID in the request URI.
Why is this not included in this request?


*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?


*PUT /todos/{id}*

I am assuming that the {id} in the request URI above is the todo id? Is
that the case?
I am not clear on the role of the ownerID; can you please elaborate on this?

Regards,
 Rifaat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240228/c618897c/attachment-0001.html>