0070 XLS-70d: On-Chain Credentials #202
Replies: 6 comments 2 replies
-
|
Great Proposal. Just some thoughts in no order I would keep this all under the issuer. I don't own my drivers license or passport, thats exclusive property of the goverment. Same with a Financial Advisor approving accreditation status. That user cant take it or do anything with it. Intuitively I know the issuer and the user. I would look under the issuer, for the user's VC. But thats just me maybe there are examples where its reversed. I also think you should think about this in actual real world application. Take a DMV example. The issuer is the CA DMV. The verifier is the clerk, and the subject is me. The DMV needs to be able to add and remove clerks. That clerk is who is authorizing the VC. I need to know who authorized it. Under this each clerk is the issuer. Thats not really how I would structure this. Same for DEFI accreditation. The issuer is the organization, the verifier is the financial advisor, the subject is the client. I made an example how I would do this using smart contracts. https://github.com/Transia-RnD/xhs-library/blob/main/test/integration/did/did.test.ts I also wonder if URI is even necessary and the fact that it is not updatable makes me think it shouldn't be an actual URI. In the DMV example, I'm not going to store that PII information publicly. So it would most likely be an auth url. Which means that I can change the data anytime I want for the user, but also, sometimes url's change, maybe v1/v2 or maybe I just made a mistake and need to change them. I would store the Drivers License ID as the URI, then in whatever application I know where to look (the full url) if I need the details. But thats just me. I know there are others out there using these same principles. |
Beta Was this translation helpful? Give feedback.
-
|
How would a user know a |
Beta Was this translation helpful? Give feedback.
-
|
A minor update to this spec was published today, 2024-07-12. |
Beta Was this translation helpful? Give feedback.
-
|
A minor update to this spec was published today, 2024-07-23. The only parts updated were the |
Beta Was this translation helpful? Give feedback.
-
|
Per the new XLS Contributing process, it is my opinion that we have reached a "well-refined standard." As such, I propose that we move this discussion to a file (via #211) and work on final changes using additional PRs, for better change-tracking. Please comment here if you would like to object to moving this spec/discussion forward in the process into a DRAFT spec. (Note that per the Contributing guidelines, moving a spec into the DRAFT state does not mean any kind of endorsement, nor does it mean that this specification will become adopted. It is solely meant as a mechanism to enable better change tracking using PRs.) |
Beta Was this translation helpful? Give feedback.
-
|
Closing this discussion since the spec has been initially merged via #211. For further discussion or changes, please open a PR in this repo on XLS-70d. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
An updated version of this spec can be found here: XLS-70: Credentials.
The earlier version can be found by looking at the edit history.
Beta Was this translation helpful? Give feedback.
All reactions