Closed tomdaffurn closed 1 month ago
in-market use has shown that many commercial OAuth 2.0 implementations elected to issue access tokens using a format that can be parsed and validated by resource servers directly, without further authorization server involvement
So is the idea that the credential issuer will validate the proof jwt's nonce against the access token's nonce? 🤔 yeah I like it! nice!
did we have a concrete use case for the addition of jti
? I'm presuming it's an indexed column in the db for lookups?
did we have a concrete use case for the addition of
jti
? I'm presuming it's an indexed column in the db for lookups?
No strong need for it, but it's REQUIRED in RFC9068. It definitely can be a DB ID. It also makes each token unique
@tomdaffurn @KendallWeihe @decentralgabe @mistermoe Hey guys for any future KCC changes please add me to the conversation, I don't want our guides to ever become outdated/misleading. - thanks!
hey @EbonyLouis I would recommend 'watch' ing the repo so you auto get notifications I will also add you as a codeowner
Great idea, thanks @decentralgabe !
Propose a fatter access token:
aud
. This is our Issuer, which will probably be the same DID as our Authorization Server, but they are distinct in OAuthclient_id
. The applicant DID from SIOPv2 request. Will be the same assub
, but is required by the specjti
c_nonce
abdc_nonce_expiry
. These are included so the Credential Endpoint / Issuer can consume the token without calling back to the Authorization server. It's fewer fields in our DB. They're not part of RFC9068, but are endorsed by it: