Unfortunately, it actually causes the merge problem above. [UPDATE @oed was talking the OTHER merge case. Sorry, entirely my bad The bit below is still useful I think]
Repeating here for the group/discussion here: duplicate key handling is under-specified in the JSON spec, and thus different libraries handle them differently:
When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable. Many implementations report the last name/value pair
only. Other implementations report an error or fail to parse the object,
and some implementations report all of the name/value pairs,
including duplicates.
JSON parsing libraries have been observed to differ as to whether or
not they make the ordering of object members visible to calling
software. Implementations whose behavior does not depend on member
ordering will be interoperable in the sense that they will not be
affected by these differences.
However, we could solve this by wrapping it in an array. Adapting your example above:
Will mention what I said in the other thread as well. I think it would be easier to solve the merge problem by simply not allowing duplicate resource keys?
That’s a change we could make, yeah. It does mean that there’s more things that people can mess up in an implementation, and it’s not a problem that we have in the existing version of UCAN. Not forcing this eliminates a Byzantine (buggy not malicious) case.
If this example is used to make a request, you could be subject to a confused deputy vulnerability. That’s why a capability designates a single resource.
There are two options for this example. You could return a separate capability for each resource, or you could only accept a request if the capability designates a single resource. The former case takes up more space, and the latter requires delegating to yourself. I don’t view either of those to be much of a problem.
The example is just the delegation, the actual request (=invocation) happens on one specific capability, e.g., my.resource.1 + append, or my.resource.1 + delete, etc.
Does this address your concern?
I like the arrangement of the JSON representation, it’s great. w.r.t. the statement generation, we have been thinking about how to make namespaced actions like crud/read more obvious. We suggest factoring out the common namespace for actions into a prefix separated with a :, e.g. crud/read + crud/write becomes crud: read, write. In this way, a recap like
would become: I further authorize https://example.com to perform the following actions on my behalf: (1) crud: "read" for "http://example.com/public/photos/". (2) other: "action" for "http://example.com/public/photos/". (3) crud: "read", "delete" for "https://somwhere.else".
It factors out the namespace to make each clause define the actions from one namespace for one resource. I think this helps emphasise the purpose and makes it a bit harder for a reader to skip over an action that isn’t expected to be there
I think that many URIs will be unparsable for regular users, but we couldn’t think of a way to make them easier to read in a general case by manipulating them somehow. That’s still a nice to have for us but we are fine right now with using whole URIs in the statement.
The main concern I would have is that the crud part of your example doesn’t get wrapped in "". A developer could potentially introduce spaces and special characters there. Maybe ReCap should specify which strings are legal as actions?
I think quoting the crud would be a good suggestion. when it comes to legal strings in general, some characters will naturally have to be illegal, e.g. newlines which would break the siwe statement, or slashes / which conflict with the json representation (like crud/read)
The bit below is still useful I think]
