-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wallet notifying the Issuer of (un)successful issuance of credential(s) #70
Conversation
callback_endpoint
: OPTIONAL. URL of the Credential Issuer's Callback Endpoint as defined in (#callback_endpoint). This URL MUST use the https
scheme and MAY contain port, path, and query parameter components. If omitted, the Credential Issuer does not support the Callback Endpoint.Co-authored-by: Giuseppe De Marco <[email protected]>
two options on the table discussed during the call:
|
personally, I like option 2 much more. it adds (yet another) identifier, but still feels better than sending an entire credential... |
I like option 2 too. As long as confusion about identifiers can be avoided. |
thinking more about it, I think there is a confusion which
|
to solve how to identify the status of each credential when more than one credential was issued, I added an option to return callback_id from credential endpoint and batch credential endpoint, which wallet needs to put in the callback. so callback depends on the issuer returning a callback_id, which should be fine. |
This reverts commit 0f50200.
@@ -1191,29 +1193,115 @@ Cache-Control: no-store | |||
} | |||
``` | |||
|
|||
# Notification Endpoint {#notification_endpoint} | |||
|
|||
This endpoint is used by the Wallet to notify the Credential Issuer of certain events for issued credentials. These events enable the Credential Issuer to take subsequent actions after issuance. The Credential Issuer needs to return the `notification_id` in the Credential Response or a Batch Credential Response for the Wallet to be able to use this Endpoint. Support for this endpoint is OPTIONAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This endpoint is used by the Wallet to notify the Credential Issuer of certain events for issued credentials. These events enable the Credential Issuer to take subsequent actions after issuance. The Credential Issuer needs to return the `notification_id` in the Credential Response or a Batch Credential Response for the Wallet to be able to use this Endpoint. Support for this endpoint is OPTIONAL. | |
This endpoint is used by the Wallet to notify the Credential Issuer of certain events for issued Credentials. These events enable the Credential Issuer to take subsequent actions after issuance. The Credential Issuer needs to return the `notification_id` in the Credential Response or a Batch Credential Response for the Wallet to be able to use this Endpoint. Support for this endpoint is OPTIONAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few editorials still to be applied, overall approved. Thx!
* `invalid_notification_id`: The `notification_id` in the Notification Request was invalid. | ||
* `invalid_notification_request`: The Notification Request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, or is otherwise malformed. | ||
|
||
It is at the discretion of the Wallet whether to retry the request or not. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're now saying this in two different places (line 1206 as well). We should only say it in one place.
I do not think we should encourage or even allow the wallet to retry for a permanent failure, for example I don't think invalid_notification_id
or invalid_notification_request
should ever be retried.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good now, I just requested two small changes
@@ -1191,29 +1193,115 @@ Cache-Control: no-store | |||
} | |||
``` | |||
|
|||
# Notification Endpoint {#notification_endpoint} | |||
|
|||
This endpoint is used by the Wallet to notify the Credential Issuer of certain events for issued credentials. These events enable the Credential Issuer to take subsequent actions after issuance. The Credential Issuer needs to return the `notification_id` in the Credential Response or a Batch Credential Response for the Wallet to be able to use this Endpoint. Support for this endpoint is OPTIONAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This endpoint is used by the Wallet to notify the Credential Issuer of certain events for issued credentials. These events enable the Credential Issuer to take subsequent actions after issuance. The Credential Issuer needs to return the `notification_id` in the Credential Response or a Batch Credential Response for the Wallet to be able to use this Endpoint. Support for this endpoint is OPTIONAL. | |
This endpoint is used by the Wallet to notify the Credential Issuer of certain events for issued credentials. These events enable the Credential Issuer to take subsequent actions after issuance. The Credential Issuer needs to return one or more notification ids in a Credential Response or a Batch Credential Response for the Wallet to be able to use this Endpoint. Every notification id is related to exactly one issued Credential. Support for this endpoint is OPTIONAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this belong in the definition of "notification_id" itself?
Co-authored-by: Giuseppe De Marco <[email protected]> Co-authored-by: Torsten Lodderstedt <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm - please approve my editorial suggestion before merging
Resolves #32. migrates PR608 from bitbucket.
need to agree how the wallet specifies about which credential it is talking
proof might not work because there is no requirement for the proofs to be unique across credentials..
using format/type structure might work when combined with the identifiers in PR add identifiers for issuing credential of the same type, different content #65