Closed wyc closed 2 years ago
dhh1128
commented
4 years ago It's a big deal to me to be able to express this in a proof (presentation) request; pushing this into downstream business logic means we validate such things with something other than verifiable credential tech, which means we have to invent a new strong form of proof, do we not? Without such features, I think the spec is fatally flawed and becomes uninteresting to me.
wyc
commented
4 years ago So @dhh1128 I'd like to run a few specific use cases by you to see if I fully understand what you mean. I have some further questions and also a proposed implementation. Could you let me know if I got what you meant and if you have any of the answers? Thanks
credentialSubject.id.credentialSubject.id to be properly authorized.credentialSubject.prosecutorId must match the prover's DID. However, credentialSubject.id can be for anything.adjudicate-case privilege with respect to New York City's trust framework {"uri": "https://nyc.gov/tf/courts"}medical-license-issuer privilege with respect to the AVICENNA Directory for Medicine ({"uri": "https://www.wdoms.org/tf/medical-schools"}) or accredited-medical-school privilege in FAIMER World Directory of Medical Schools ({"uri": "www.faimer.org/tf/school-listing"}).Here are aspects of an impl:
credentialSubject.id to match a specific DID, e.g. did:ethr:0xdeadbeefcafe. I feel that we should avoid using derived variables like $proverDID in the Presentation Definition for now.issuer property, including those for specifying trust frameworks/privileges.cc @csuwildcat for visibility
dhh1128
commented
4 years ago Yes, you've captured the spirit of my terse notes in far better detail. Thank you.
I would note that your first 3 examples all assume that the way to bind the credential to the prover is via a disclosed public DID value. I know this is generally assumed to be the way it works in VC circles, but it has never been the canonical way of doing the binding in ZKP circles. There, the binding has been viewed as a far more nuance-able characteristic (and this is why the VC spec says "MAY" about the id property of a holder, instead of "MUST"). In a ZKP credential, you can bind a credential to a prover by exposing a public DID value (which the prover demonstrates they control). This is straightforward, but has at least two limitations: 1) it conflates the distinction between the controller and the DID subject. When someone-claiming-to-be-Alice shares a VC that contains Alice's DID and proves control of that DID, what has been proved is NOT that the party you're interacting with is Alice, but rather that the party you're interacting with controls Alice's DID. The DID spec requires these to be viewed as two different things, though in practice the distinction often collapses. This allows games to be played (e.g., Alice's legal guardian can satisfy half a proof with credentials about Alice, and half with credentials about the guardian, since the only binding property you have is the commonality of control). I have always wondered when this subtlety would bite the VC community; I intuit that there are cases where it will matter, but have not attempted to suss them all out. 2) it has privacy/correlation problems, as we all know.
In ZKP land, you can also bind a VC to a holder using proof-of-link-secret control (instead of or in addition to a public DID). Although a link secret can be shared, sharing it after issuance won't allow the sort of controller=subject conflation that DIDs do, so combining the techniques may be useful. Perhaps more interestingly, you can also bind using a biometric, a situational attribute, a password, a capability token, etc. Each of these would be a different verification method in a DID doc. So it would be good to genericize your first 3 examples slightly by requiring that a binding be proved, and leaving how it is proved as something that could have multiple concrete implementations that are not mutually exclusive.
Can you link to or walk through some examples of how to verify properties around an issuer?
The issuer is qualified by trust framework, either directly ("in our trust framework, we trust DIDs X and Y to issue college diplomas") or indirectly ("in our trust framework, an institution can issue college diplomas if it can prove it possesses an accreditation credential from DID Z"). Note that in the second case, any VC-provable characteristics are possible qualifications for the issuer, and the way you would express those qualifications is with a new presentation definition that qualifies the issuer, when satisfied. It is also conceivable that the trust framework would specify the qualifications of the issuer in ways that are not VC-provable (e.g., "the issuer must talk on a public IP address from this range or this geo" or "the issuer must possess a TLS cert from one of these CAs").
The issuer is qualified by verifier criteria. This can be expressed and evaluated exactly as if by trust framework; the difference is that the criteria are chosen by the verifier without regard to a trust framework.
Note that #1 and #2 are combinable; they are not mutually exclusive.
Presently, the Presentation Definition is only concerned with property-level extraction from whatever pile of VCs are thrown at it. If we want to verify things like issuers of a specific credential from which we derived Property X, not sure if there's a natural expression how the standard is currently. Just to confirm, this is what you want to be able to confirm, right?
Yes, this is what I want. The issuer of a cred is already a property in the VC, so it should be totally uncontroversial to be able to express requirements about the value of that property. If we can't do that much, then anybody can issue a driver's license or passport, and we have no way to express which ones we will accept. Most of the more extended characteristics I'm suggesting we support are VC-provable. They don't require new language in a spec; they just require the issuers to have VCs of their own.
Related to this is the idea of provenanced data and chained credentials (see Aries RFC 0104). If presentation definitions supported this concept, we would be able to express a requirement like this: "Prove to me the name and birthdate from your employment credential, and prove to me that the employment credential based this assertion on data that your HR department observed in your passport." Note that the latter clause in the proof is, again, NOT a new construct that requires modifications to the VC spec; instead, we're saying that the prover must disclose to the verifier not just the normal fields of a credential, but also a field called provenanceProof which is, itself, a self-contained verifiable presentation that demonstrates "HR observed this in your passport." In other words, the only thing we have to do to get this power in our presentation definitions is allow them to be recursive.
I think if we took your suggestion of splitting Presentation Definition into a static Presentation Definition and instance-based Presentation Request in #23, we could possibly include a simple way to specify property values that must be matched in the Presentation Request. For example, we could require a property to have its relative credentialSubject.id to match a specific DID, e.g. did:ethr:0xdeadbeefcafe. I feel that we should avoid using derived variables like $proverDID in the Presentation Definition for now.
I agree. I did not propose derived variables like $proverDID.
We could consider syntax to add constraints to the issuer property, including those for specifying trust frameworks/privileges.
I don't think we need this. We simply need to allow a presentation to be recursive, and to change subject at each level of recursion: "Prove with A's credentials that issuer X [did] asserted Y and Z; prove with X's credentials that W, V."
David-Chadwick
commented
4 years ago First and foremost the above use case is flawed. It is not how things operate today and is not how they will operate in future. If you open a new bank account today, either online or by visiting the bank (both operate today in the UK) thenBigbank is not in the least bit interested in Alice's DID. What Bigbank is interested in is Alice's identity, not her identifier. It wants to see the details from her state-issued identity, such as name and address and DoB (but not about which vehicles she can drive) and secondary proof of address from a current utility bill. It also wants a PoP that these VCs belong to Alice, so it will want a portrait photo to match with the face of the person sitting in front of the bank clerk (on site registration) or device camera (online registration). And that's it. The DID is a red-herring that only serves to confuse the search for a working solution with VCs.
dhh1128
commented
4 years ago @David-Chadwick : I find myself simultaneously agreeing and disagreeing with you. The agreement is tied to "BigBank is not in the least bit interested in Alice's DID. What BigBank is interested in is Alice's identity, not her identifier." To me, this is totally correct and uncontroversial. Violent agreement.
However, I feel like it misses the point in a sense. What Wayne's framing assumes is that we have to map high-level, human interests as describable by untrained, non-technical humans into the data format of a presentation definition. And that means we have to point to something in the presentation def that gives the humans what they want. That thing is the binding between the credential and the person. It is supposed to accomplish nothing for Alice to share Bob's credentials, if she's opening an account for Alice; Alice should have to share Alice's credentials to satisfy the bank as verifier. How do we ensure that? By expressing our binding requirements. Wayne gave the canonical binding requirement: prove control of a DID that the credential asserts is controlled by Alice, so we have reason to believe the prover is (or is a controller for) Alice-the-subject.
Said another way, if a request for VC-based evidence can't say something about the prover-to-credential-subject relationship that a verifier needs to see, the evidence will be useless. Sure, a VC describing Alice has been presented, and Alice's identity has been studied/revealed/shared. But since we don't know that the party doing that presentation is actually Alice, the bank can't open the account. (The complexity of this issue becomes more clear when we think about credentials with multiple subjects, such as a birth certificate. A government considering the issuance of a passport may ask to see a VC-formatted birth certificate to establish facts of birth. But if the holder of the birth certificate, and the applicant for the passport, is the mother rather than the child, then the birth certificate in question is irrelevant. Just because Alice's child is a French citizen doesn't mean Alice is. We MUST have a way to express this sort of requirement in our requests for evidence.)
wyc
commented
4 years ago @David-Chadwick I'm hearing you say that BigBank cares about Alice's "proofed" identity, as demonstrated by a state-issued identification card and a utility bill, and that the DID is not necessarily relevant at all. This makes sense to me.
However, there seems to be another requirement here--that Alice's identity proofing is bound to a specific authenticated session, whether established in person, over an cookie-authenticated HTTPS session, or through DID-based communications. Could it be relevant in this way? We could even imagine slotting out the DID for an OpenID Connect token that Alice got from login.gov, already proofed to an appropriate assurance level of authentication.
csuwildcat
commented
4 years ago Let's throw in something that basically makes the DID case crystal clear: assuming acceptance, Alice wants the bank to have an identifier they know her by, which she owns/controls independently of that relationship, to do things like:
Basically, you'll need a DID to do the 99.99% of identity things that aren't directly within/about the VCs themselves.
David-Chadwick
commented
4 years ago That thing is the binding between the credential and the person.
I totally agree. This is what I referred to as PoP - proof of possession. But Binding is also an acceptable term for this. So PoP should be proven crytographically and biologically. The former only proves the binding between the device or session and the VC, the later between the VC and the person. (In fact we could dispense with the former if the latter is really strong and unbreakable, so this is why I only mentioned this in my original post).
prove control of a DID that the credential asserts is controlled by Alice,
This is not good enough because it does not prove control by Alice but control by a key or device holding a key. I can give my device holding my keys to a friend, and they can masquerade as me. This is why the portrait photo matching is also required (as it is today when registering for an online bank account).
Alice wants the bank to have an identifier they know her by, which she owns/controls independently of that relationship,
I refute that requirement. It does not matter a jot what Alice requires. It is only what the bank requires that matters. If you dont satisfy the bank's requirements you wont get a new account. So this requirement is a red-herring.
csuwildcat
commented
4 years ago I refute that requirement. It does not matter a jot what Alice requires. It is only what the bank requires that matters. If you dont satisfy the bank's requirements you wont get a new account. So this requirement is a red-herring.
From my experience talking to countless enterprise customers (including many banks) in my work at the largest software company on the planet, I assure you enterprise customers are keenly interested in pushing personal data out of their systems to reside with users for a myriad of reasons, including: reduction of liability, GDPR compliance, and other security-related drivers. Beyond that, the enterprises that adopt DIDs + personal datastores will be able to provide new and better services that other competitors simply can't via the old model of ID/data capture within proprietary silos.
David-Chadwick
commented
4 years ago Pushing personal data out of their systems can easily be done without the need for DIDs. For example, the bank validates the user's identity from the set of VCs that the user presents, and then issues the user with one new VC. It only stores the PII it needs to store to comply with GDPR (in fact even this isnt needed because it can always ask the user to represent the identity VCs at any time). All the user needs to present from now on is the bank issued VC to be uniquely identified and authorised by the bank. No DIDs are needed.
csuwildcat
commented
4 years ago @David-Chadwick I am going to list a series of user stories, and I would like you to tell me how you'd accomplish them without a DPKI system + decentralized personal datastores:
Please detail for me how you would create such a system without IDs that are owned and controlled by users, that aren't trivially interdictable and subject to the whims of central providers/silos (ex: email addresses, centralized app usernames, etc.), wherein the data does not reside in provider-centric services or centralized app silos.
Go!
David-Chadwick
commented
4 years ago csuwildcat
commented
4 years ago
- Who owns this datastore (hardware software)? Who pays for it? The standard personal datastore instances would be run on the user's devices + other places where you can freely store encrypted data today (e.g. cloud storage services that offer free tiers)
If you do (solely or jointly with others) then you can do whatever you want with this resource and devise your own P2P or DLT system for it.
As a user, this would be a standard, not a one-off, random setup - the work for this is already underway in DIF's Secure Data Storage WG.
But if others own it and require you to pay for it, then they will require you to identify yourself before they will grant you access.
I can create random burner emails to get free cloud storage today, and there is no reason to believe I will have to show a driver's license to get the same exact type of free service tier.
In this case you cannot avoid having one or more trusted identity providers in the system. It is simply not possible for two strangers to identify themselves without a TTP. DIDs don't cut it since they don't identify you, they only authenticate you (unless you were to violate all the privacy principles and have just one DID that everyone everywhere knows you by and all your identity attributes are linked to it).
I think you are confusing use cases - for all the app-related personal datastore use cases, there is no need to identify myself for the purpose of an app storing its data with my personal datastore.
A simple asymmetric keyID is sufficient on enrollment to ensure it is always you each time your return - but this is authentication not identification.
Not being able to roll the keys and endpoints related to my ID and the datastores that it points makes the use of a raw public key a nonstarter - DIDs solve this.
- You can easily delegate your privileges to others by issuing the others (people, things etc) with VCs in which you are the issuer and they are the subjects. Its called DoA.
Besides the fact that the VC would need to be associated with the common identifier that stands for you, which both the delegated party and the datastore could resolve, this is beyond a simple bearer access token: permitting access will often require a shared symmetrical key that permitted parties secure via DID-encrypted exchanges, such that the security of the system is not bound to a provider's service.
- If you have a set of standard APIs available to you as a developer, then you use them and dont care how they are implemented. Its not your concern.
Of course, but for the use cases presented, I would again challenge you to accomplish the things I am talking about with a bunch of centralized, siloed services - that route conflicts with the underlying requirements presented.
In general, ABAC systems only need to know the user's identity attributes, and can work out the permissions based on these attributes. Identifiers are not needed, but people implement identifiers as a simple way of uniquely identifying each user in the system, rather than using a unique set of the user's identity attributes. This false belief that identifiers are needed has led to the belief that DIDs are needed.
Identifiers are needed, because the remote personal datastore location must be able to resolve the current PKI key/routing state without requiring in-band connection to the user.
wyc
commented
4 years ago We are getting off-topic. For purposes of moving this spec forward I propose we agree that there seems to be a need to describe relationships between the Holder, Issuer, and Subject. These could be DIDs but they don't need to be, as described in vc-data-model (see issuer, for example). Here are the outstanding items for which we can hope to reach resolution:
Any objections to that?
csuwildcat
commented
4 years ago @wyc no objections here. What is the outcome in terms of the spec? Is there going to be a PR that changes the language we use?
David-Chadwick
commented
4 years ago None from me, thanks
wyc
commented
4 years ago Discussion from WG:
csuwildcat
commented
4 years ago Several folks in this meeting echoed the realization that to do this effectively without introducing some rather intractable conditions or a cascade of downstream credential issuance/schema requirements, we really need something like a Hub. This is because no matter how one articulates the need for a chain of proofs about, or related to, the credentials being submitted (e.g. the diploma credential you submit must be from a university that itself has a credential that proves it is an accredited institution), you need a sane way to find and retrieve that proof as a Holder or Verifier (depending on who is doing the legwork). To this end, we feel it is best to look at this as something that needs a solution, but may require other specs/solutions to achieve. For now, the proposal is to mark this as something we need to solve as soon as we can, but do so in a way that doesn't encumber the spec with things it can't solve on its own.
OR13
commented
4 years ago @csuwildcat can we get a concrete proposal for a workaround in absence of "Hub"...
like serviceEndpoint URIs, etc...? I always prefer to look at some json over reading walls of text :)
csuwildcat
commented
4 years ago To illustrate how this probably should be done, at a high level:
Either way works, but you need an inferentially knowable place to get an object/cred of the type you seek - aka: Hubs
csuwildcat
commented
4 years ago @csuwildcat can we get a concrete proposal for a workaround in absence of "Hub"...
like serviceEndpoint URIs, etc...? I always prefer to look at some json over reading walls of text :)
Personally, I will not invest a single second of my time inventing a special server/endpoint for looking up a single object type. That would be a foolish waste of effort that should be rolled into making a service/endpoint that handles the same inferentially knowable storage and lookup functionality for all types of objects. Creating a service/endpoint for a specific type of object as if they are all special snowflakes is pure insanity, and will lead to there being 100 different endpoints for fetching thousands of common objects. If this happens, I will be duty-bound to relentlessly mock everyone involved, until such time that the community capitulates and admits they should have just built the damn Hub to begin with. (none of this angst is intended for you or anyone on the thread, it's just general frustration that folks have ignored what I continue to believe is the single most important component required for this to all work, besides DIDs themselves. But I digress)
csuwildcat
commented
4 years ago Basically, this:
dhh1128
commented
4 years ago One way to provide this without hubs is described in Aries RFC 0104. Please note that the mechanism outlined there has no dependency on ZKPs; it will work for all types of VCs.
csuwildcat
commented
4 years ago @dhh1128 embedding linkages to associated credentials within a credential (either by direct credential reference or to the location of associated attesters) isn't a tractable solution, imo. There are 1:Many cases where a cred can't possibly point to all the associated creds a verifier may want to check. Additionally, there are many cases where dynamic associations with upstream creds occur post-issuance, meaning you wouldn't have the references to an associated cred/issuer at the time of issuance. The dynamic nature of endpoints (along with the 1:Many association case) would also prohibit baking a series of query locations into credentials, as those could change, break, etc. after issuance. The only serious way to do this, imo, is to use DIDs for what they do best - a decentralized PKI and routing layer - to crawl for these things in a way that isn't brittle and can automatically handle just about every use case imaginable in this problem set.
csuwildcat
commented
4 years ago Proposal: specify that requirements of credential Issuers will be exclusively in the scope of the Verifier's evaluation, not defined in the spec for v1, but we will add notes to make this clear.
dhh1128
commented
4 years ago I can live without a lot of the fanciness, but it is absolutely non-negotiable to be able to express a requirement like, "the DID of the issuer must be a member of the following list." While a verifier can enforce this without having support for it in the language, the verifier has no way of helping the prover know that they're looking for this requirement unless it's part of what's in the spec. "Give me an employment credential" is not very helpful without saying, "Give me an employment credential <from this DID, which is an employer I trust>". "Give me a diploma" isn't very helpful without being able to say, "The only diplomas I'm interested in are ones from these issuers." Verifiable credentials are, at their heart, far more about the question "Says who?" than they are about the question, "Says what?". It's the "who" question that confers the trust.
Do we already support this? If so, I'm cool with Daniel's proposed deferral of the rest of my requested features. But without even the ability to require a particular issuer DID from a set, the spec's dead in the water, IMO.
wyc
commented
4 years ago @dhh1128 we support this as a string matching for the issuer field or any other field, including any within credentialSubject, as such:
"input_descriptors": [
{
"id": "banking_input",
"schema": {
"uri": ["https://bank-standards.com/customer.json"],
"name": "Bank Account Information",
"purpose": "We need your bank and account information."
},
"constraints": {
"limit_disclosure": true,
"fields": [
{
"path": ["$.issuer", "$.vc.issuer", "$.iss"],
"purpose": "The credential must be from one of the specified issuers",
"filter": {
"type": "string",
"pattern": "did:example:123|did:example:456"
}
}
]
}
},
// ...
]Is this okay for v1, with fancier stuff to come? Of course the downside is that referencing a large set of issuer identifiers does not scale well. Furthermore, we need to resolve https://github.com/decentralized-identity/presentation-exchange/issues/27 to make sure the constraint actually makes sense.
dhh1128
commented
4 years ago Okay, if we can do that much that I am okay with deferring the rest.
brentzundel
commented
4 years ago per the meeting 9/3/2020: The spec already provides the minimal capabilities desired.
dhh1128
commented
4 years ago I propose that we close this issue, as I was the source of the original question even though @wyc kindly logged the issue for me. I think we've accomplished what we needed to in terms of analyzing it.
csuwildcat
commented
2 years ago Your terms are acceptable, @dhh1128
re: https://github.com/decentralized-identity/presentation-exchange/pull/18/files#diff-9308a2575ae14de31b25f4459ecfc604R100
re: https://github.com/decentralized-identity/presentation-exchange/pull/18/files#diff-9308a2575ae14de31b25f4459ecfc604R107
TODO: add examples, cc @dhh1128
Perhaps this is out of scope for now because these checks can be done downstream by the business logic with data that are further provided. But it's certainly useful for a wallet to know additional constraints around a field, even if it must piece that data together from disparate systems.