add new notification concepts and pending states, remove callback con…#31
Conversation
dickhardt
temporarily deployed
to
github-pages
GitHub Actions
Inactive
|
|
||
| ## Notification Token | ||
|
|
||
| A Notification Token is a JSON Web Token (JWT) signed by the RP. The OP validates the signature using the RP's published keys (e.g., via the `jwks_uri` value that the RP provided in the Metadata Response). To avoid cross-JWT confusion, Notification Tokens MUST include a `typ` JWS header of `notification+jwt`. |
There was a problem hiding this comment.
You will eventually need to add an IANA media type registration for application/notification+jwt.
|
|
||
| ### Notification Types | ||
|
|
||
| The `notification` claim in the Notification Token payload indicates the type of notification. This specification defines the following values: |
There was a problem hiding this comment.
It would reduce surface area and overlap with other state change mechanisms (e.g webhooks, SSF, etc) if metadata_change or audit_tenant_change are just notifications to an async OP command that contains a last updated timestamp.
The OP would send audit_tenant_async with a last_updated timestamp and if the RP didn't have any changes to return it would defer the async notification until a change in state occurred in the RP. The OP would then process async results and would issue a new audit_tenant_ async with a current timestamp. This would keep all notifications as a response of a async processing of command vs RP state changes. The OP may also need to poll the RP anyways at intervals as it may not want to rely on the notification to keep its state up to date as there isn't a heartbeat or anything to know if the RP is "healthy" and notifications weren't lost.
3 participants
…cepts