Code Monkey home page Code Monkey logo

Comments (14)

kimdhamilton avatar kimdhamilton commented on June 9, 2024

From @ChristopherA on July 12, 2017 0:24

BTW, the logic of my ordering of these different spectrum words started with the name of the working group, Verifiable Claims.

  • INTEGRITY CHECK includes malformation and cryptographic signature or proof checks - this is defined by the signature system spec
  • INSPECT INTO means looking inside for something and then going outside to get it — this is defined by the data model spec
  • VALIDATION means that the conform to rules of the DID spec and the specific DID method.
  • VERIFICATION means that that everything is self-consistently INTEGRAL, the INSPECTIONS reveal no problems with VALIDITY, and thus the whole can be VERIFIED.
  • CONFIRMATION relies of the VERIFIABLE CLAIMS to then make possibly more human judgements on different trust models to be used by the Web-Of-Trust. It also somewhat analogous to Bitcoin's terminology, where transactions require multiple CONFIRMATIONS.
  • REVOCATION deals with the edge cases where things go wrong. There may need to be processes associated with "where things go wrong" at each the stages above, as revocation currently may be an overloaded term.

from vc-data-model.

kimdhamilton avatar kimdhamilton commented on June 9, 2024

From @ChristopherA on July 12, 2017 1:27

The topic of revocation will be much harder to define — in fact, we probably need as many stages and roles for it alone as the above has about the spectrum from integrity to confirmation.

What they all the forms of revocation have in common is to help us with deal with the edge cases when things can go wrong.

The simplest case should be expiration. However, does the fact that someone have a certificate that says they were married in 2018 and the claim expired in 2028 and the issuer isn't around anymore (or doesn't issue marriage certs to gay couples anymore) mean that the claim is invalid? Or that the college course I took on English History is no longer valid? Or maybe the Javascript course I took SHOULD be invalid because no one uses version 8 anymore. Especially in a world where we can now do time stamps, what does an old but expired claim mean? Who decides — the issuer, the subject, or the holder that the claim was given to?

What if it isn't precisely expiration, but that various conditions of the issuer or other requirements are no longer true, but not entirely false? A subscription has expired, but the check is on the way. A continuing education requirement didn't happen, but is in progress? Something is being disputed in court of law. Then there there may be requirements that the holder has that are higher than that of the issuer? Or that the holder of the claim don't care about X and Y, but do care about Z?

One suggestion by many cryptographers is to move toward very short lived keys, or even keys that are used only once. Tricks like HD keys and different forms of blinding can allow this. But then in Verifiable Claims, there is a value to persistence and an appropriate latency where holders may "hold" on to claims for some time, and the benefits of this architecture of holding may be lost if they essential have to recheck too often.

Another use case that should be easier is what to do when a key is compromised. Clearly ideally the key should be rotated so that no new claims are issued, and that can be a step in the INTEGRITY CHECK and INSPECTION tasks above. But the real challenge is what does that mean for various parties that relied on those keys in the past? Does everyone who got a diploma in 2020 have to get a new one when the key was compromised in 2022? What happens if a key can't be rotated? It is a difficult challenge now when you have a hierarchy of keys and a high level one is compromised, but a web-of-trust may be more complex due to the intertwining of claims and counterclaims. Can I countersign your claim, then revoke it, and hurt your claim?

Another challenge is when the keys are all valid, but fraud or faulty evidence is involved. That information revealed didn't conform to HIPPA or other privacy laws, etc. How do the parties notify each other? As Peter Wuille said in #2 and covered again in #25 censorship resistance is very important to revocation.

Another challenge is that of changes, of requirements, of affiliation, superseded, cease of operation, etc. In my own case, I taught for 5 years for a leading graduate school in sustainable business. Along the way, it change it's name from bgi.edu to pinchot.edu, and according the rules of .edu, you can't have two domains, so no forwarding of emails was allowed. Now the school has been acquired by presidio.edu, an entirely different legal organization, and all my mail to both academic email address now all bounce, and all staff at the original institution are gone (the admin offices moved from Seattle to SF). It is hard enough for me as a former staff, but what about the 14 years of graduates of the school, which was prestigious for its type, accredited, etc. when you can't even go to the website listed on their diplomas? Some is true for former employees, change of roles, etc. and apply to issuers, subjects, and holders.

In most cases it is issuers that revoke, but in self-sovereign identity, where a subject has more equality with an issuer, a subject may wish to revoke. In the even more radical self-sovereign BTCR method, all claims must also be countersigned by the subject, what happens when the subject wants to revoke an issuers claim? How do they notify all the holders?

With multisig, we also have the ability to have our peers revoke our claims. I could set it up such that if 2/3rds of my peers see my digital world misbehaving, and thus evidence of a compromise (of my keys or my mind), they could rotate my keys to a guardian until we figure out what went wrong.

If the goal of revocation is to help deal with the edge case, they ideally should also allow the "human" element to be able to step in. We don't want the tyranny of the algorithm in all cases. If there is a volcanic disruption in Seattle or a hurricane in Miami, we don't want a bunch of revocations forcing house liens and compounding the problems that the residents who are recovering are having.

Finally, revocation can be an attack vector for bad actors. How do we prevent that? What about sybil attacks? Ransomware? In the case of BTCR, bad actors can also be state actors. What if China tells a bunch of their citizens and companies to revoke claims, but the EU says no. Who do you listen to?

I'm fairly sure that I've not covered the whole breadth of the issues possible with revocation, and I certainly don't have any easy answers, but I hope this is a good start toward thinking about the problem.

(The next section will discuss what might be possible for Revocation for the initial implementation of BTCR)

from vc-data-model.

kimdhamilton avatar kimdhamilton commented on June 9, 2024

From @ChristopherA on July 12, 2017 2:15

In our user story of Alice, the Syrian Hacker Army is targeting her as the author of an Android app that helps Syrian refugees communicate with the families back home and send them care packages through a random peer-to-peer network of people sharing their car trunk capacity. An Uber of small gifts, an AirBNB of trunk space.

Alice has been careful with her cryptographic keys, but she has prepared herself. The special set of public keys that are associated with this app are listed in her DDO, and she has a password protected QR-code of the control key for the current DID and DDO, but the owner keys to update the DDO to a new transaction is with a friend in England locked on a hard drive.

Unfortunately, while traveling through Turkey, Alice's laptop is stolen. She is suspicious that someone might be targeting her.

The first thing she could do is just revoke and abandon the DID by simply spending the tip address. However, she doesn't have the owner keys to enable that DID owner key rotation transaction—they are in England. She does however hold the current control key, so she can use that to update the DDO object that might be a possibly compromised key. She puts a "hold" notice in the DDO, and adds a timestamp to warn people to no longer rely on values in the current DID transaction until resolved, and wait for the new transaction on the tip.

When she returns home to England, she spends the tip, revoking the old control key, and enrolling the old owner key as the new control key. A new address is posted which will be the next owner key and the new "tip".

She now updates the DDO itself, signing it with the control key just enrolled. She has no evidence of any key compromise yet, but she in her DDO that only claims issued her using her revoked old control key are valid if they were dated before the time the key was stolen, and that any claimants should request to update claims if possible. As all of her claims are timestamps, there is no way for someone to fake a claim even if they break her old key, as the signature may be valid, but the timestamp is not.

It is also possible that she could have set up her owner key to be 2 of 4 multisig, with keys held by her trusted colleagues Bob, Carol and Donna. In this case, if two of them observed bad behavior in claims being issued by the old DID/DDO, or if she was able to call at least two of them, they could immediately rotate the owner keys, and give her the new owner key when she gets home. She maybe even already has the new owner key, at it could have been generated by an xpub her friends share (however, this technique does require two transactions rather than one for every owner key rotation).

Finally, at some point in the future she passes this mobile project on to another team to develop, and she gracefully "retires" the DID/DDO pair with a gentle revocation and no new possible owner key. However, all of her non-expiring claims are still valid — she didn't issue many, but a few are important and they need to remain.

from vc-data-model.

kimdhamilton avatar kimdhamilton commented on June 9, 2024

From @ChristopherA on July 12, 2017 2:18

A reminder: there will likely in time be other specific techniques for doing revocation, see #2 and #25.

from vc-data-model.

kimdhamilton avatar kimdhamilton commented on June 9, 2024

From @ChristopherA on July 12, 2017 2:20

A question for @jandrieu: I know that you like to keep your 15 step use cases to be technology-agnostic, but what steps in your model am I missing from the above?

I'd love to get from our graphic facilitators a little graphic image based on the stories above for each of your 15 steps, and present those 15 steps and how they work with the current BTCR concept as a slide deck.

from vc-data-model.

kimdhamilton avatar kimdhamilton commented on June 9, 2024

From @jandrieu on July 12, 2017 3:8

@ChristopherA I'll dive into the mapping to 15 steps later tonight, but I wanted to suggest a distinction that I hope will help reduce the complexity of revocations.

Without some sort of general knowledge engine, aka, AI, we can never algorithmically know if any given statement is true or justified or appropriate. We may be able to tell if it is intended as a statement of fact rather than opinion through semantic analysis or rigorous RDF predicates, but in essence, the merit of a "statement" that is the payload of a verifiable claim is not algorithmically auditable.

What we can do is verify the integrity of the payload. That is, that the payload is, to all algorithmic tests, the payload that was published by the author and remains unrevoked. Or to use VC terms, the statement is verifiably the same as the one made by issuer (as defined as the controller of the issuer's keys) and none of the optional revocation mechanisms show it revoked.

The distinction I suggest is that revocation should only be applied to the verification of the integrity of the payload, and never to the integrity, validity, applicability, or truth of the statement.

So your questions:

However, does the fact that someone have a certificate that says they were married in 2018 and the claim expired in 2028 and the issuer isn't around anymore (or doesn't issue marriage certs to gay couples anymore) mean that the claim is invalid?

It means the claim can no longer be verified. It's like presenting an expired insurance card to a cop in a traffic stop. It doesn't mean anything about whether or not there is currently valid insurance. Just that the credential presented is not itself verifiable proof of current insurance. Because of the risk of compromised keys, it should, in fact be treated as a non-statement, a no-op. However, it may be useful forensically to seek out alternative proof of valid insurance. For example, the insurance company and contract id may still be sufficient for looking up a current verifiable claim. So it isn't completely useless.

Or that the college course I took on English History is no longer valid?

That begs the question of what "valid" means. For VC conversations, I'm extremely careful about using valid to mean well-formed in terms of the data-model and verified to mean algorithmically tested (based on the signature and revocation method).

To say that the course is invalid, begs a further question. Valid for what?

I had a circuitous route through my undergraduate degree and there was an "understood" rule that courses taken over ten years ago were no longer valid for graduation requirements. There was also an explicit rule that one could graduate under any catalog under which they were a student. Turns out the graduation requirements changed during my 13 year adventure. Because of fears that my early coursework might not be valid, I was accommodating rather than confrontational with the Registrar when reviewing my graduation requirements, which mean I took a few extra courses not in the original requirements. I didn't argue about my right to graduate under the older catalogs and she never brought up my "invalid" courses.

The point of that entire story is that the merit of a given statement is entirely contextual and beyond the scope of what verifiable claims can address. What we can do is verify the payload in question was both initially issued by someone with the keys to sign the claim and that since then, no one with the appropriate revocation authority has revoked that claim.

That's it.

Anything beyond the verification and revocation mechanism is policy and context.

That said, I do think there is a place for a general policy hook in both credentials and entity profiles. I raised this issue in #48 In brief, issuers should be able to specify terms of use of a credential, which are signed (and hence verifiable) and holders should similarly be able to specify terms of use for an entity profile.

The question of what those terms are and how we specify them is a whole other question.

That suggests strongly to me that any notion of expiry of a claim--outside the terms of use--should only be treated as a component in the verification of the claim and not the expiration of the statement.

For example, for the insurance case, I may have a VC that is short-lived because it's tied to having paid my insurance this month. It may contain a credential describing an insurance policy that expires next year. The short-lived claim expiry should apply only to its acceptability by an inspector, independent of the expiration of the underlying policy as represented in the credential. Once the VC is accepted by the inspector, they may then choose to rely on the expiration in the payload for triggering a notification that I need to renew my proof of insurance. If I were to present that original VC after the short-lived expiry, it should be treated by the inspector just as if the cryptographic check of the signature failed.

from vc-data-model.

kimdhamilton avatar kimdhamilton commented on June 9, 2024

From @jandrieu on July 12, 2017 16:48

After sleeping on it, I think we also need to bring up the update/amend techniques. I raised this a year ago in the VCTF, but didn't get traction on it.

However, if DIDs are specifically designed to enable updating DDOs without changing the URL (and they are), and if DDOs are verifiable claims (and that has been proposed), then we are explicitly building an architecture to update claims.

Yes, the operation is most likely replace, but this entire function has been adopted without a deep discussion of what it would mean to amend/replace a claim.

A key distinction from revocation is that this is revocation with a replacement. So that a recipient of the amended claim, when checking for revocation, could retrieve the replacement claim. Currently, other than the implicit relationship of dereferencing DIDs to get a "current" DDO and the reciprocal DID entry in the DDO, we don't have any discussion about this replacement architecture.

We ran into this with Joram 1.0.0, as he changed camps and the new pharmacist didn't find his prescription because of filters limiting his search to 'scripts from his camp. He updated the data store (somehow) so that future prescription searches would find the new one, and somehow, magically, the prior 'script was no longer valid for fulfilment.

A key question is whether or not the Holder has any role in this update. Perhaps it is the Holder's job to check the revocation/update status before giving a VC to an inspector and if they fail to do that, the claim is always subject to updates (potentially leaking unintended information). Or we could make the case that the ONLY operation is revocation, but I think that misses some use cases where we want a consistent identifier to always resolve to the latest claim, even if it has changed. Like with a DDO.

Of course, with DDOs, the holder and issuer are identical, so the self-referential loop from DID->DDO->DID enforces currency.

But what about other use cases?

from vc-data-model.

kimdhamilton avatar kimdhamilton commented on June 9, 2024

From @dlongley on July 12, 2017 17:25

In my view, I don't think DDOs should be claims, but rather, they may embed (or link to) credentials that contain claims.

When dereferencing a DID, you get a DDO, which is a document that contains a graph (or RDF dataset) where the main node in the graph lists relationships (RDF predicates) between the entity the DID identifies and other nodes or literals. One such relationship could be a list of credentials belonging to the entity. These credentials may be self-issued (where the issuer is the DID entity and is identified by its DID) or they may be issued by a third party.

In other words, a DDO is just an "Entity Profile" from the Verifiable Claims Data Model. It is one view of the entity identified by the DID (a self-sovereign, self-reported view) -- and it may contain credentials that include verifiable claims that assert the properties and values found in the profile.

I'm short on time this week so I can't elaborate much further at the moment, but I wanted to put this out there.

from vc-data-model.

kimdhamilton avatar kimdhamilton commented on June 9, 2024

From @jandrieu on July 14, 2017 18:44

That sounds right, @dlongley

from vc-data-model.

stonematt avatar stonematt commented on June 9, 2024

@kimdhamilton and @msporny are there still open elements to this issue? I see several commits that address this thread.

from vc-data-model.

kimdhamilton avatar kimdhamilton commented on June 9, 2024

I'm not sure; I ported this from the BTCR Hackathon. It was originally entered by @ChristopherA -- anything still open Christopher?

from vc-data-model.

msporny avatar msporny commented on June 9, 2024

We have section 6 in the spec now. I'm +1 for closing this issue.

If there are further issues, then folks should re-raise more specific ones on subsections in section 6.

from vc-data-model.

dlongley avatar dlongley commented on June 9, 2024

We've addressed this issue with section 6 so we're closing this out. More specific issues within the context of section 6 should be submitted should they arise.

from vc-data-model.

stonematt avatar stonematt commented on June 9, 2024

Closing the issue based on group consent and comments above.

from vc-data-model.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.