credential_pop typ with status-attestation-request+cwt + huge editorials #37
Conversation
this commit may resolve issue peppelinux#20.
peppelinux
changed the title
Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it>
The Content-Type has been changed from application/x-www-form-urlencoded to application/json.
Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it>
Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it>
Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it>
Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it>
| @@ -384,7 +385,8 @@ When the JWT or CWT format are used, the JWT/CWT MUST contain the parameters def | |||
|
|
|||
| | Payload | Description | Reference | | |||
| | --- | --- | --- | | |||
| | **iss** | Wallet identifier. | {{RFC9126}}, {{RFC7519}} | | |||
| | **iss** | Wallet identifier. The Wallet identifier is out of the scope of this specs considering that it may be just a | |||
There was a problem hiding this comment.
the wallet identifier is not a framework
There was a problem hiding this comment.
The last sentence ("considering that....") is not clear to me. Is there a reason why we decided to emphasize that the Wallet identifier is out of the scope of this spec? I suggest removing this sentence., if you agree.
@OR13 @marinaado
There was a problem hiding this comment.
@fmarino-ipzs the way a wallet can be identified or the value to be supposed to be used for identify a wallet is definitively out of the scope of this spec
…est" Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it>
This commit aims to resolve the following comments: - peppelinux#37 (comment) - peppelinux#37 (comment)
peppelinux
changed the title
|
This PR is ready to be merged, a further PR will be create to address @marinaado 's comment #45 (comment) and the table related to the errors where the placeholder is here defined: https://github.com/peppelinux/draft-demarco-oauth-status-attestations/pull/37/files#diff-6018989306b8996e79d471eb123fc3b59796d1635384b6faac8cdb36cd5f49ccR472 regarding the first comment, since it is required that the status assertion issuer always respond with an application/json containing the status_assertion_errors, I'd try to use a general approach without defining specialized error section for both the requests and the responses |
this commit may resolve issue #20.