Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make resource collection URLs explicit #206

Open
adrianhopebailie opened this issue Oct 25, 2022 · 6 comments
Open

Make resource collection URLs explicit #206

adrianhopebailie opened this issue Oct 25, 2022 · 6 comments
Labels
type: specification Changes to the specification

Comments

@adrianhopebailie
Copy link
Collaborator

Currently the resource collection URLs that are used to create and list resources are implicit.
e.g. Given a payment pointer https://example the resource collection for creating new incoming payments is https://example/incoming-payments.

There seems to be no advantage to this given that we require a client to get a grant to access any of these URLs.

A cleaner and more extensible solution would be for the server to provide the URL of the resource collection to the client as part of the grant response.

Example: AS response for grant to create/read incoming payments

{
     "access_token": {
          "access": [
               {
                    "type": "incoming-payment",
                    "actions": ["create", "read", "list"],
                    "locations":["https://example/incoming"]
               }
          ]
     }
}

From this response the client knows that it must perform create and list operations by making a POST or a GET to https://example/incoming.

@wilsonianb
Copy link
Contributor

wilsonianb commented Oct 25, 2022

Would https://resource-server-url/incoming be the standard?
Or would the RS need to register the corresponding (sub)resource urls (locations) with the AS?
https://datatracker.ietf.org/doc/html/draft-ietf-gnap-resource-servers#section-3.4

@wilsonianb
Copy link
Contributor

It looks like locations is intended to represent an RS, as opposed to a collection
https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#section-8

@adrianhopebailie
Copy link
Collaborator Author

Or would the RS need to register the corresponding (sub)resource urls (locations) with the AS?

This

It looks like locations is intended to represent an RS, as opposed to a collection

I think that the concept of an RS is less specific than you're implying. In theory it could be possible to have an entirely different RS for each resource collection. These are a perfectly valid set of RS URLs for different resource collections:

As with all of the other URLs returned by API responses we should avoid assumptions about the authority or path relative to the API request URL.

@adrianhopebailie
Copy link
Collaborator Author

@sabineschaller - any thoughts on this idea?

@mkurapov
Copy link
Contributor

mkurapov commented Oct 2, 2024

@adrianhopebailie given we now have resourceServer and authServer as properties on the wallet address, probably less relevant? Unless you see the benefit of resource-specific URLs, although that might complicate things more.

(we are just doing some issue cleanup)

@mkurapov mkurapov added the type: specification Changes to the specification label Oct 2, 2024
@adrianhopebailie
Copy link
Collaborator Author

@mkurapov I agree this is no longer relevant

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: specification Changes to the specification
Projects
Status: Backlog
Development

No branches or pull requests

3 participants