- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Tue, 17 Jan 2017 12:16:17 +0000
- To: "opencreds/vc-use-cases" <reply+00574006094fbab04d33bf3eb41ada44398bb4e41fac7da692cf000000011495cabe92a16>, "opencreds/vc-use-cases" <vc-use-cases@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>, W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAM1Sok3i9Pvk6fBr1n+VQibYmQ2EQnhuJHVUu8=QuPNM09_fOg@mail.gmail.com>
i quickly found: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-16-1-distributed-ledger-technology.pdf Which appears to provide 'beyond blockchain' information about decentralised ledgers. On Tue, 17 Jan 2017 at 23:06 Joe Andrieu <notifications@github.com> wrote: > I'd like to suggest rewriting Section 5 User Sequences to instead use > Constantine & Lockwood's Essential Narrative format. Not only should this > avoid some of the dependence on architectural assumptions, e.g., user > agents and credential repositories, but it would help clarify the flow of > the user experience independent of the underlying technology. > > Here's a strawman example of Issue Claim as an Essential Narrative. Note > that although the claim is issued by the Issuer, it is the Holder who > drives the interaction: > User Intention System Responsibility > 1. Request credential 2. Authenticate user (optional) > a. Request identification > b. Provide identification c. Verify identification > 3. Present claim for confirmation, with target ledger > 4. Confirm claim and ledger 5. Sign claim > 6. Publish verifiable claim to ledger > 7. Present claim reference > 8. Save claim reference > > This particular flow illustrates some questions I have. > > First, authenticating the user is optional and its order may vary. I think > the most common case is logging in to the website first with > username/password, then asking for the credential, but it seemed more > inline with the use case to start with the intention as getting the > credential. There is agreement that there is no requirement for the issuer > to authenticate the user, correct? > > Second, "credential repository" is listed a "a storage vault or ... wallet > that stores and protects access to ... credentials and verifiable claims" > However, this confusing to me. > > Neither the use cases nor the data model present any language about > blockchain or ledgers, and yet my understanding is that a public ledger is > key to the notion of self-sovereign identity and therefore, key to > Verifiable Claims. I understand that we are NOT specifying protocols at > this stage, but am I correct that there is an unstated expectation that > claims are stored not just directly in a filesystem or database, but in a > ledger and then reference in a wallet? > > Third, is moving a claim mean moving it from one wallet to another or from > one ledger to another? There is currently no distinction between > substitutability of wallets and substitutability of ledgers. It seems to me > that if we don't ensure portability between ledgers we don't really have > portability. Is it currently expected that one may move a claim from one > ledger to another? If so, how does that work for revoking and/or amending > claims? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/opencreds/vc-use-cases/issues/33>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFdABgn97RVzNtCgZwkCj7gBJgwugahwks5rTK6-gaJpZM4LlkPM> > . >
Received on Tuesday, 17 January 2017 12:17:00 UTC