Token format

[Denisthemalice]

Currently in OAuth, the token format is negotiated privately between the RS and one AS. Changing the token format requires a close synchronization for every AS/RS relationship.

More flexibility should be offered. In order to negotiate the token format, every AS and every RS should be able to advertise the token format(s) that it supports.

This should be part of a RS discovery phase and an AS discovery phase.

[fimbault]

Partly discussed already in #145 and #169 (but those relate more to the internal structure).

Following a discussion between editors: "In the core, take the approach that the client library shouldn't care. But there's room for a additional document that defines a common structure." (I agree with that).

Yet, I personally would be in favor of knowing the format type (jwt, paseto, json-ld, macaroon, biscuit, whatever).

[Denisthemalice]

Issue #190 addresses the case;

The token_profile allows the client to advertise to the AS the access token profiles supported by the RS. This is rather important since this does not mandate anymore any prior relationship between ASs and RSs.

jwt, paseto, json-ld, macaroon, biscuit, whatever can be advertised by the RS and be blindly transmitted to the AS by the client.

The client does not need to understand the structure of jwt, paseto, json-ld, macaroon, biscuit, whatever ...

[fimbault]

Don't need a token_profile as such (as explained I think a RS discovery mecanism is out of scope), but you might just support headers as suggested in #203 Accept-GNAP-tokens: "jwt", "whatever" (list what is supported)

Indeed the client would have no need to understand the format (neither its content nor its serialization), but GNAP could then be fully agnostic (and therefore enable cryptographic innovation, instead of just allowing basic jwt cases).

note: that's a personal view (different from the OAuth2 world), not as an editor / but I think it would align well with the vision of GNAP's AS being "primarily a token issuer" (cf discussion on the mailing list)

[Denisthemalice]

At the moment the issue #203 is dealing with an error case. You are proposing to add:

Accept-GNAP-tokens: "jwt", "whatever" (list what is supported)

This would not hurt.

However, as I already wrote in another issue, a key question is whether we want support a clean discovery mechanism and/or a discovery by trials and errors. One of these two approaches does not prevent the other.

[fimbault]

Another example of multiple formats https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/

[jricher]

Token format negotiation and discovery is introduced in GNAP-RS extension created by #246

[Denisthemalice]

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

246 is not currently addressing the token format negotiation.

A token format negotiation implies both a query to the RS and a query to the AS made by the client, so that the client can indicate to the AS (in case of a match) one access token format.

This issue should not be yet closed