Closed sappenin closed 4 years ago
I've updated the PR to soften the language around the SIMPLE
profile. I think it's sufficient to keep the RFC to "tradeoffs" and allow any two peers to decide which of the three profiles to use. Feel free to call out anything I missed in this regard.
Is there scope to include a profile that is more like OAuth 2.0. i.e. the token is opaque but it is not "pre agreed" between the parties.
@adrianhopebailie I tried to limit the spec to only normalizing "authentication" claims in JWTs, but also tried to leave room for any other claims if desired (e.g., authorization claims). Speak up if you think something is missing, but any of the tokens (well, the JWT's at least) should be usable in an OAuth 2.0 flow.
@sappenin I wasn't looking to include other claims but rather change the way you describe the SIMPLE profile.
I think this may also make @emschwartz and @sharafian happier.
Basically, OAuth allows the access token to be either a "handle" (opaque) or something like a JWT which encodes the data.
When a resource server gets a request carrying the token it performs "introspection" to determine things like the subject, expiry, audience, scopes etc of the token.
Introspection can mean:
Out of interest, the OAuth provider we have used for our POC does not use JWT's as access tokens, it uses an opaque token and has some security reasons why they recommend that but I can't find those docs right now!
So, perhaps we can describe SIMPLE as something else that is more along the lines of an "opaque token plus introspection" and then provide guidance on the issuance of the token such as setting an expiry?
Found the link: https://www.ory.sh/docs/hydra/advanced#json-web-tokens Thanks @matdehaast
Closing this in-favor of https://github.com/interledger/rfcs/pull/565
HTTP Auth is now a proposal in the /proposals folder per the new CONTRIBUTING guidelines.
Replaces and enhances the work done as part of https://github.com/interledger/rfcs/pull/531