[Openid-specs-ab] OP Commands Notification ideas

[Dick Hardt]

Hey

Reflecting on the call yesterday and building on an offline discussion I
had with Karl today, I wanted to float some ideas on notifications.

1. We add async versions for each command that could by async. This then
has an RP declare which calls are async and which are synchronous. IE, we
add the following commands:

activate_async
maintain_async
suspend_async
delete_async
reactivate_async
archive_async
restore_async

An RP would likely only support the sync or async version of a command. IE
`activate` or `activate_async`

The OP would pass an additional parameter when calling a *_async command
that the RP would use when notifying the OP at command completion.
Including the parameter is optional by the OP.

Similarly the OP may optionally include a similar notification parameter in
the `metadata` command that the RP would use when it has new metadata and
wants the OP to issue a new `metadata` command.

This parameter would be one time use, reducing the security risk of
leakage.

The parameter could be an opaque URL that contains context for the OP, and
could be an opaque token the RP passes back to the OP at a fixed
notification_endpoint.

Thoughts?

/Dick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250415/f3cc7b7c/attachment.htm>