Concept of a "service" supported by a set of RSs

[Denisthemalice]

At the moment an access token is intended to be presented to one server, i.e. a RS.

There are cases where a Service (SRV) is supported by a set of RSs, e.g. a printing service or a storage service.

If an access token includes the name of a service (in addition to an identifier of a RS), either :

• that access token may be forwarded by one RS to another RS belonging to the same service, or
• the client may re-use the access token at another RS belonging to the same service.

This avoids the RS or the client to ask for a new access token.

The implication is as follows: every RS should be able to advertise the name of the service(s), it belongs to.
This can be done using a RS discovery operation.

[fimbault]

RS discovery seems like an overkill for what is fundamentally an internal detail of the RS. That use case is better managed via tokens that allow delegation (and also enable a better tracking that the second order delegation has been processed by the RS). That's one of the microservice implementations we've been discussing previously.

[Denisthemalice]

The first text clearly mentions that the notion of a service is able to support two mechanisms instead of one.

• an access token may be forwarded by one RS to another RS belonging to the same service, and
• the client may re-use the access token at another RS belonging to the same service.

The first case could indeed be supported by asking a new access token, but the merits of this proposal
is precisely to avoid to request another access token.

Furthermore, this proposal avoids to consider RSs as clients from the point of view of the AS.
In terms of privacy, it has the advantage of keeping the AS ignorant from the fact that a RS is forwarding a request to another RS.

Don't forget that if the access token only contains some kinds of attributes, the AS can be kept ignorant of the identity of the RS.
This is an additional advantage in terms of privacy.

[jricher]

The described process is already possible within GNAP (section 2.1), and the GNAP-RS extension created by #246 goes into greater depth on requesting resources and deriving tokens for internal requests as needed.

[Denisthemalice]

This issue has been marked "Pending Close", however its content is important.

The mechanism described in section 2.1 is rather different and much more complex than supporting the concept of
a "service" supported by a set of RSs.

The two mechanisms can co-exist.