Replies: 1 comment
-
My crack at the above: A1. Holder component should be decomposed from the storage component. The storage component should have requirements around the secure zone. A2. Security/Privacy features - some sort of 'authentication' or challenge/response. Depends on what 'unauthorized access' actually means A3. These requirements can be put into the storage component, as it applies to issuer, verifiers and holders. A4. Likely different requirements for issuer, holder, verifiier, but all around secure storage. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Questions to address
How can you trust data being held in the holder component (data at rest)? Should it be encrypted? Should it be in the secure hardware zone in the case of a mobile device?
What security/privacy features need to be in place to protect data held in the holder component? Should there be any requirements for preventing unauthorized access?
What do we need to test to determine that sufficient security/privacy/data management due diligence has been done with the holder component so a user can trust their data being held in there, issuers can trust issuing sensitive information there and verifiers can trust requesting information from there?
Same questions for the issuer and verifier components. It is beyond just certifying that it acts like an issuer, verifier or holder component, but that it at least meets minimum expectations regarding security, privacy, etc. Maybe also accessibility?
Beta Was this translation helpful? Give feedback.
All reactions