Convert Sequences to Essential Narratives

[jandrieu]

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, does 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?

[ghost]

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
2. Present claim for confirmation, with target ledger
3. Confirm claim and ledger 5. Sign claim
4. Publish verifiable claim to ledger
5. Present claim reference
6. 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 .

[jandrieu]

Indeed. @ChristopherA also pointed out that the properties of a decentralized ledger can be described without dependence on blockchain technology. What isn't clear to me is whether or not (1) there is consensus that verifiable claims implies a decentralized ledger and if so, (2) whether or not we should be explicit about that distinction.

[ghost]

@jandrieu I think part of the problem is the challenge to produce, as mandated, the relatively simplified counterpart of an identity ecosystem - verifiable claims (specifically). @msporny initial works (whilst i'm sure an array of contributors were involved and I will defer to @msporny for broader clarifications) included the use of WebDHT http://opencreds.org/specs/source/webdht/ however this was also at a time prior to the specificity provided (ie: transition to verifiable claims) by stakeholders effectively became a more focused...

Melvin worked on decentralising the block-chain using linked-data, somewhere in there manu / dave (from memory) created linked-data-signatures; and at some-stage respect network (who once upon a time had a thing where people were invited to "reserve their name" via an older concept) got involved with creds/vctf - and now, i'm not really sure what's going on with that field of stuff; other than considering,

It's probably not good for humans to excessively burn energy for the simple reason that we build a system of trust that depends upon the manufacture and operation of specialised computational equipment homeowners are unlikely to invest in; and,

the difficulty is likely that whilst people may have a 'decentralised verifiable claims' infrastructure solution they need somewhere to put it. IMHO consultation should be had with the https://www.w3.org/wiki/WebID group. https://www.w3.org/blog/webauthn/ is another area that likely needs to be looked into (alongside the use of WebID) and interop with LDP is likely important also. I have alot of faith in https://tools.ietf.org/html/draft-cavage-http-signatures-06

yet, i'm thinking the use of blockchain in documentation is perhaps... well... maybe we need to invent something new. LDDL Linked Data Decentralised Ledgers. or whatever...

digital preservation is another important requirement. I'll add it.

[msporny]

There is agreement that there is no requirement for the issuer to authenticate the user, correct?

There is no such requirement. In practice, an issuer acting in good faith and generally trusted by the community will do some sort of vetting of the user before issuing a credential. If they don't do this, then the verifiable claims that they issue can't really be trusted.

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?

That is not correct. DLTs are NOT a requirement for Verifiable Claims to be useful. Verifiable Claims are identifier agnostic, thus you can use any of these identifiers for an entity:

https://example.com/people/joe
urn:random:3f7j29cj238fj4
ipfs:QmTzQ1JRkW...YQ7c15n
did:ex1:38d9-f3232-f2dd-joe

The last one in the list, if it's on a DLT and provides the sort of functionality provided by DIDs, is a good basis for Self-Sovereign claims. However, that work is experimental and thus the Verifiable Claims work MUST NOT depend on it.

To be clear, Verifiable Claims are a much more fundamental technology than DIDs and DLTs and Self-Sovereign identity. Yes, Verifiable Claims can be used in the scenarios listed in the previous sentence, but they are also useful in other scenarios.

Third, does moving a claim mean moving it from one wallet to another or from one ledger to another?

It can mean both. Digital Bazaar expects that the claims are moved from one wallet to another upon the decision of the Holder (in that, there is no vendor lock-in).

It seems to me that if we don't ensure portability between ledgers we don't really have portability.

Be careful not to mix the term "portability" with "interoperability". Standards tend to focus more on the latter than the former. If we don't have a protocol that is capable of moving VCs between wallets, we don't have portability. If we don't have a data model and expression format that is used among different wallets or ledgers, then we don't have interoperability.

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?

There is no such expectation because that is an active area of research.

Digital Bazaar has designed the current Verifiable Claims protocol that enables one or more claims to be moved from one digital wallet to another. Talking about data being "moved" from one ledger to another feels like the wrong way to talk about things as ledgers are immutable, so there is no such thing as "moving". It is conceivable that you could write the same verifiable claim to two ledgers, revoking it on one ledger to simulate a "move". In any case, this is far outside the scope of the Verifiable Claims WG (but inside the scope of the Credentials CG).

[msporny]

What isn't clear to me is whether or not (1) there is consensus that verifiable claims implies a decentralized ledger and if so, (2) whether or not we should be explicit about that distinction.

It is provable that Verifiable Claims DOES NOT imply a decentralized ledger.

We will probably want to be explicit about that distinction because it continues to be a source of confusion.

[msporny]

@mediaprophet said

LDDL Linked Data Decentralised Ledgers

That is exactly what this work is about:

https://w3c.github.io/flex-ledger/

[ghost]

;) I'll had another look... IMHO the vocab is confusing as the generic understand of blockchain (from Satoshi's paper) is different to a decentralised ledger that's leveraging off linked data.

I also liked WebDHT, or DHT generally, but not clear about the future of these elements yet.

Although, I think perhaps we might be able to figure out the principals?

On Wed., 18 Jan. 2017, 1:19 am Manu Sporny, notifications@github.com wrote:

@mediaprophet https://github.com/mediaprophet said

LDDL Linked Data Decentralised Ledgers

That is exactly what this work is about:

https://w3c.github.io/flex-ledger/

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/opencreds/vc-use-cases/issues/33#issuecomment-273176982, or mute the thread https://github.com/notifications/unsubscribe-auth/AFdABvfP7NZRNuzEvavDeZBPQgPWWMJjks5rTM4BgaJpZM4LlkPM .

[msporny]

I'll had another look... IMHO the vocab is confusing as the generic understand of blockchain (from Satoshi's paper) is different to a decentralised ledger that's leveraging off linked data.

Discussion about definition and usage is happening here:

https://docs.google.com/document/d/1BNKQ-hNFIpROyzQRig7a7kTBcmclAQlbv3MCCZfhHiE/edit#

I also liked WebDHT, or DHT generally, but not clear about the future of these elements yet.

The WebDHT work as well as authorization.io was used as the basis for two things:

1) The basis for the DID specification, which a number of us are collaborating on at RWoT. 2) The basis for the Flex Data Format and Protocol.

So, WebDHT has expanded into those two areas of work.

[jandrieu]

@msporny Great. That helps. I was getting hung up on the lack of explanation about how revocation is enabled in the data model.

My current understanding: If the claim ID is a DID with a scheme that supports revocation, then we don't need anything else--inspectors use the DID mechanism. However, if the claim ID is a URL that doesn't have a known revocation method, then the claim section must provide a revocation. In both cases, in order to validate a revocable claim, inspectors need to be able to query an authoritative source. That could be a distributed ledger or just an http URL.

This suggests two things to me.

First, the privacy difference between querying a live server (http URL) and a distributed ledger should be explained, somewhere. IMO, a primary distinction of ledger-based self-sovereign identity systems is that there is no "identity provider" who gets queried every time an inspector needs to validate a claim. This is a big deal.

Second, non-revocable verifiable claims should probably be marked as such within the claim itself (such that it is a signed statement by the issuer). Alternatively, the existence of a revocation URL could provide the same information in the inverse. Offline inspectors should be able to know, by local inspection (and crypto math) that a given claim is complete or not. If the claim is revocable, then the offline inspector needs to know that the claim cannot be considered valid without checking for revocation. If it isn't, it can be treated as a bearer token and recognized. And, in this case, "offline" means no access to an up-to-date revocation authority for that particular claim. The requirement to be "online" could be met by an offline system which has a recent copy of the ledger, where "up-to-date" and "recent" are quality parameters for the inspector, i.e., as long as this credential wasn't revoked in the last 24 hours, we'll accept it (and the offline inspector gets ledger updates every 24 hours)...

So far, this requirement for access to the revocation authority (whether DLT or live service) is not well described (yet) in the use cases.

Am I following how this works? I'll be updating the use cases based on my understanding. It appears the "amend claim" use case also needs some sort of authority for a claim to be complete.

[msporny]

If the claim ID is a DID with a scheme that supports revocation, then we don't need anything else--inspectors use the DID mechanism.

I don't think that there is a DID scheme that "supports revocation"... and even if there was, we may want a unified way. We need a data model for revocation.

Am I following how this works?

Yes, more or less... you've got 95% of it right, and the rest are details we can get to in implementation.

[msporny]

Added issue to add revocation section to specification: https://github.com/opencreds/vc-data-model/issues/34

[burnburn]

Discussed in 24 Jan 2017 telecon (link to minutes when available)

[davidnicol]

hello. I'd like to restate my usual peculiar point of view here. (1) by considering a ledger to constitute all book entries made in a currency, which is out of the standard box, as everyone is used to dollars at one bank being the same as dollars at another bank, and not questioning/appreciating the existing reliability of fractional reserve banking as an expression of a single underlying book-entry ledger, questions about the boundaries between ledgers can get clarified. A USD account at Wells Fargo winds up in the same ledger as a USD account at Chase, and the ledger is the vast and existing banking system. A Bitcoin account at Bitpay winds up in the same ledger as an account at Coinbase, the BTC blockchain. "same ledger" means "low-friction fungibility." (2) centralized/decentralized, physically, is meaningless here, and the terms are confusing. "administrative domain" is a useful concept, but "decentralization" is an implementation detail. Blockchains, although physically distributed, are under unified administration, even if that unified administration is by a committee free to split into no-longer-interoperable factions. Thank you for your patience.

[jandrieu]

Work moved beyond this. We won't be including this in the Use Case document.