RE: Cryptographically Enforceable Issuer Policies (forked

Let me first repeat the disclaimer that I’m not 100% sure that what I say is correct, but it is what I so far have understood to be the case. I’m currently trying to write a small paper in which I provide details of how this should work, a draft of which I expect to be able to share somewhere in the coming weeks.

The following paragraphs are responses to earlier mails, oldest first.

@Steve Magennis<mailto:steve.e.magennis@gmail.com>: The figure you provided is not correct. The issuer does NOT need to provide the policy to the KeySmith; the KeySmith doesn’t need to know what the issuer-policy looks like. He’s only smithing keys.
I like the graphics though. What tool do you use for that?

@Adrian Gropper<mailto:agropper@healthurl.com>: Policies are only defined by the issuing party, and end up in the encrypted credential, and optionally in advertisements of issuers that they publish (e.g. in a Credential Catalogue) so that other parties can decide whether or not they have value for them. Describing the policy and related stuff would help such parties make that decision.

@Adrian Gropper<mailto:agropper@healthurl.com>: Parties that play the role of issuer may also want to play the role of KeySmith (and also the other roles of holder and verifier). However, it is not required. There may be a real benefit to outsource the KeySmith role to a separate party, which I expect to explain in the upcoming paper.

@Steve Magennis<mailto:steve.e.magennis@gmail.com>: I don’t think there needs to be any ‘calling home’ that would be bad. Specifically because a party that needs to get a decryption key can obtain such a key way before it actually needs to use it, and it can use it to decrypt every credential that the issuer has issued under the related policy (and possibly other policies as well). I hope the upcoming paper will enhance all our understandings of this.

@Adrian Gropper<mailto:agropper@healthurl.com>: The view that a data subject MUST have maximum control over a credential in which it is (apparently the only) subject and the issuer as little as possible rules out many useful use-cases. One example is in the context where an experiment is conducted with medicine, where some patients get a placebo and others the experimental drug. The pharmacy wants to issue a credential to patients stating whether the patient got the placebo or the real drug. If the patient could see this while the experiment is running, that would jeopardize the experiment. Still, a party that can prove it belongs to the group that is conducting the experiment might find such a credential quite useful.
I consider the view that “the choice to trust the issuer should be the subject’s alone” to be unrealistic, in the sense that I do not see that it works in the real world. To me, it seems a denyal of the fact c.q. reality that parties are autonomous, i.e. have the capabilities to collect, store, process and disseminate data and will consequently use these as they see fit. And that is regardless that these capabilities are postulated as (univerals human) ‘rights’, e.g. in the ECHR.

Rieks

From: Adrian Gropper <agropper@healthurl.com>
Sent: zaterdag 22 mei 2021 09:12
To: Jim St.Clair <jim.stclair@lumedic.io>
Cc: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>; Naveenaa <n.a.karthikeyan@student.utwente.nl>; Steve Magennis <steve.e.magennis@gmail.com>; public-credentials <public-credentials@w3.org>
Subject: Re: Cryptographically Enforceable Issuer Policies (forked

You can’t be self-sovereign if someone else is running your authorization server. (As in: children are not self-sovereign).

Adrian

On Fri, May 21, 2021 at 11:29 PM Jim St.Clair <jim.stclair@lumedic.io<mailto:jim.stclair@lumedic.io>> wrote:
"If the subject decides it's ok to have the verifier call home, then the subject can run an authorization or presentation server.."
I certainly appreciate the academic validity of the suggestion, but in practical terms are we honestly suggesting this as a consideration?
Yes, I definitely agree with any approach minimize "phoning home" but the design has to be flexible enough for ecosystem A (that demands "phoning home" (for KYC/ZTA/etc) and ecosystem B, where it should be 100% the discretion of the holder.
I can't see any path to widespread adoption that includes running my own auth server, though..

Best regards,
Jim

_______________

[cid:image001.png@01D74EF7.AB4E8F20]

Jim St.Clair

Chief Trust Officer

jim.stclair@lumedic.io<http://lumedic.io> | 228-273-4893


________________________________
From: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>
Sent: Friday, May 21, 2021 8:01 PM
To: Steve Magennis <steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>>
Cc: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>; public-credentials <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Naveenaa <n.a.karthikeyan@student.utwente.nl<mailto:n.a.karthikeyan@student.utwente.nl>>
Subject: Re: Cryptographically Enforceable Issuer Policies (forked

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

It's only bad in the sense that much of the SSI protocol work is predicated on never "calling home" as a privacy and self-sovereignty feature. For example, a common feature such as revocation would be trivial if the Verifier could call home to check but instead we have some much more complex schemes that involve things like dead-drops to do that job.

As a privacy advocate, I would say the data subjects should have maximum control over their credentials and the Issuer should have as little control as possible. If the subject decides it's ok to have the verifier call home, then the subject can run an authorization or presentation server and avoid creating unnecessary copies and running a personal data store. In other cases, when the subject really mistrusts the Issuer, they would insist on having a copy of the credential and using only protocols that do not "call home". The choice to trust the Issuer should be the Subject's alone and Issuer protocols should be agnostic to the Subject's choice.

Here's some detail about this: https://github.com/w3c-ccg/vc-http-api/issues/186


- Adrian

On Fri, May 21, 2021 at 8:45 PM <steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>> wrote:

r.e. they might as well be calling home to the Issuer.



That sounds bad. Is it bad or am I not understanding how these interactions should work



From: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>
Sent: Friday, May 21, 2021 5:39 PM
To: Steve Magennis <steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>>
Cc: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>; public-credentials <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Naveenaa <n.a.karthikeyan@student.utwente.nl<mailto:n.a.karthikeyan@student.utwente.nl>>
Subject: Re: Cryptographically Enforceable Issuer Policies (forked



In most cases, the Issuer and Key Smitty are controlled by the same entity. That's evidenced by the transfer of policies in 1. When the Verifier contacts Key Smitty in 9., they might as well be calling home to the Issuer.



- Adrian



On Fri, May 21, 2021 at 8:25 PM <steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>> wrote:

At a high level, does this mol represent the primary envisioned interactions between Issuer, Keysmith, Holder and Verifier?



[cid:image002.png@01D74EF7.AB4E8F20]



1: Issuer submits a policy to the KeySmith

2: KeySmith records the policy and

3: Gens key pair(s) according to CP-APB

4: Issuer stores key

5: Issuer encrypts credential with key

6: Issuer delivers encrypted credential to Holder

7: Verifier wants to verify credential (presentation definition)

8: Holder delivers encrypted credential to Verifier (presentation submission)

9: Holder requests decryption key from KeySmith

10: KeySmith sends a presentation definition to Verifier based on the policy that needs to be satisfied. Verifier temporarily shifts role to being a Holder

11: Verifier (as holder) submits credential to KeySmith in the hope of being able to satisfy the requisite policy conditions

12: KeySmith confirms the policy conditions are met and provides the Verifier with the decryption key

13: Verifier decrypts the credential and proceeds with any additional verification or processing



From: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>
Sent: Thursday, May 20, 2021 10:15 PM
To: steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>
Cc: 'public-credentials' <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Naveenaa <n.a.karthikeyan@student.utwente.nl<mailto:n.a.karthikeyan@student.utwente.nl>>
Subject: RE: Cryptographically Enforceable Issuer Policies (forked



Hi Steve,



Before answering your question, let me tell you this is still stuff we are coming to grips with – it is the subject of a masters thesis that Naveena Anaigoundanpudur Karthikeyan is working on with TNO. So what I write below are ideas that I still need to see verified.



We introduce a new role, which we call `KeySmith`, that generates all keys involved. Specifically:

  *   It publishes the public key (and some other stuff) that issuers can use to encrypt credentials under their policy, and
  *   It provides a Decryption-Key Provisioning Service (DKPS) that other parties can supply attributes to and then obtain a decryption key that enables them to decrypt any credential that was encrypted under a policy that is satisfied by the attributes that the party supplied.



Determining whether or not a verifier (or a holder for that matter) can decrypt a credential relies on:

  *   The crypto-magic that is called Ciphertext Policy Attribute Based Encryption (CP-ABE);
  *   The rigor with which the KeySmith validates the attributes that parties supply as they request a decryption key.



Consequently, parties that issue credentials under such a policy must (be able to) determine

  *   That he attributes that a KeySmith uses to generate decryption keys are sufficient for expressing its policy
  *   That the process that the KeySmith uses to validate the attributes that parties provide as they request a decryption key, provides sufficient assurance that the (cryptograhpic) evaluation of the policy is also valid. And I think this is the trickiest part.



Rieks



From: steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com> <steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>>
Sent: donderdag 20 mei 2021 16:17
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>; 'Luca Boldrin' <luca.boldrin@infocert.it<mailto:luca.boldrin@infocert.it>>; 'Michael Herman (Trusted Digital Web)' <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Cc: 'public-credentials' <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Kruijssen, A. (Age) <age.kruijssen@tno.nl<mailto:age.kruijssen@tno.nl>>; Stornebrink, M.H.M. (Michiel) <michiel.stornebrink@tno.nl<mailto:michiel.stornebrink@tno.nl>>
Subject: RE: One subject, 2 VCs, 2 duplicate properties



… forking the conversation r.e. Cryptographically Enforceable Issuer Policies

@Joosten, H.J.M. (Rieks)<mailto:rieks.joosten@tno.nl>, how would it be determined if a Verifier satisfies policy conditions? Really interesting idea.



This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.