W3C home > Mailing lists > Public > public-credentials@w3.org > January 2017

Re: [opencreds/vc-use-cases] Convert Sequences to Essential Narratives (#33)

From: Timothy Holborn <timothy.holborn@gmail.com>
Date: Tue, 17 Jan 2017 12:16:17 +0000
Message-ID: <CAM1Sok3i9Pvk6fBr1n+VQibYmQ2EQnhuJHVUu8=QuPNM09_fOg@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:34 UTC