Propose an access token model
yaronf opened this issue · 6 comments
Yaron: IMO we should specify a minimal, generic format in an appendix, as a non-normative starting point for developers. It would be better than having each implementation make its own mistakes.
Fabien: A comment on access token formats: I don't think we should define our own format, but we can reference other documents such as https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token-jwt and the references to macaroons, biscuits.
Yaron: I don't think a reference to an OAuth doc would do, because GNAP makes changes to the AT semantics, e.g. by replacing scopes.
See also follow on thread: https://mailarchive.ietf.org/arch/msg/txauth/ftUeJoCNqwVYI-SZCaaow3pLOms/
@yaronf yes, we can suggest a mapping more relevant, what I had in mind is a basic mapping like
- clientid <-> client
- scope <-> access
but it will be better to be more specific, a bit in the spirit of appendix C5 from core
For the record, the OAuth draft is: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt
A mapping is possible, I'm not a great fan though.
We will want to have our own typ attribute, to prevent cross-protocol attacks.
And OMG, the OAuth draft is cramming even more claims into the one-and-only Claims IANA registry/cesspool!
You convinced me ;-)
A mapping is mostly useful as a guidance document for devs that would like to migrate from OAuth2 to GNAP, but that could be only a wiki.
We would like to avoid defining a particular token format, but agree that some advice for developers is useful. Instead, we can define a token "model", to instruct developers on which fields are useful to keep track of. Appendix C "Component Data Models" would be a good place to add this.
Frankly there's very little difference, because most implementers will translate the "model" into a straightforward JWT "format". But I can live with that.