fix: removed all the comparisons with oauth status list #51
Conversation
peppelinux
requested review from
OR13,
marinaado,
fmarino-ipzs and
SaraConsoliACN
| @@ -133,27 +133,23 @@ validity of the Digital Credentials, including their revocation status, | |||
| before accepting them. | |||
|
|
|||
| Wallet Instance: | |||
| : The digital Wallet in control of a User, also known as Wallet or Holder. | |||
There was a problem hiding this comment.
I dind't want to get in conflict about other specifications with different assumptions about what the holder, technically, is.
| # Requirements | ||
|
|
||
| The general requirements for the implementation of Status Assertion are | ||
| listed in this section. The Status Assertion: | ||
|
|
||
| - MUST be presented in conjunction with the Digital Credential. | ||
| - SHOULD be presented in conjunction with the Digital Credential. |
There was a problem hiding this comment.
according to the section below "Considerations About Revocation Verification"
| OAuth Status Lists [@!I-D.looker-oauth-jwt-cwt-status-list] are suitable | ||
| for specific scenarios, especially when the Verifier needs to verify the | ||
| status of a Digital Credential at a later time after the User has presented the | ||
| Digital Credential. | ||
|
|
There was a problem hiding this comment.
I think its okay to keep this one in
There was a problem hiding this comment.
For the scopes of this PR, the rationale about the status assertion takes out any comparison to Status List.
| There are cases where the Verifier only needs | ||
| to check the revocation status of a Digital Credential at the time of | ||
| presentation, or situations where the Verifier should not be allowed to | ||
| presentation, and therefore it should not be allowed to | ||
| check the status of a Digital Credential over time due to some privacy constraints, | ||
| in compliance with national privacy regulations. | ||
|
|
||
| For instance, consider a scenario where a Verifier's repeated access to a | ||
| Status List to check the revocation status of a Digital Credential could |
There was a problem hiding this comment.
otherwise you need a reference here?
| +-----------------+ +-------------------+ | ||
| | | Requests Status Assertions | | | ||
| | |----------------------------->| | | ||
| | Wallet Instance | | Credential Issuer | | ||
| | | Status Assertions | | | ||
| | |<-----------------------------| | | ||
| +-----------------+ +-------------------+ |
There was a problem hiding this comment.
I think it would help if we have a common base terminology between status list and status attestations, as we are adopted by OAuth WG, we've used Client instead of Wallet and Referenced Token instead of Credential. Happy to negotiate :)
There was a problem hiding this comment.
I agree with this comment, we should use the term client... and explain that wallet's are a common type of client... Ideally we could all share a reference for wallet that disambiguated, hardware, mobile, cloud and virtual wallets.
There was a problem hiding this comment.
Client wins, thank you for this.
Consider It done
This PR aims to resolve the issue #50