-
Notifications
You must be signed in to change notification settings - Fork 26
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
Token format #189
Comments
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). |
Issue #190 addresses the case; The token_profile allows the client to advertise to the AS the access token profiles supported by the RS. 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 ... |
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 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) |
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 |
Another example of multiple formats https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/ |
Token format negotiation and discovery is introduced in GNAP-RS extension created by #246 |
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, This issue should not be yet closed |
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.
The text was updated successfully, but these errors were encountered: