Re: Cryptographically Enforceable Issuer Policies (forked

@Rieks - The statements attributed to @Adrian Gropper: below are not mine!

- Adrian

On Sat, May 22, 2021 at 5:11 AM Joosten, H.J.M. (Rieks) <
rieks.joosten@tno.nl> wrote:

> 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 <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 <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 <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 <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 <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>
> 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
>
> *_______________*
>
>
>
> *Jim St.Clair*
>
> Chief Trust Officer
>
> jim.stclair@lumedic.io | 228-273-4893
>
>
>
>
> ------------------------------
>
> *From:* Adrian Gropper <agropper@healthurl.com>
> *Sent:* Friday, May 21, 2021 8:01 PM
> *To:* Steve Magennis <steve.e.magennis@gmail.com>
> *Cc:* Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>; public-credentials <
> public-credentials@w3.org>; Naveenaa <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> 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>
> *Sent:* Friday, May 21, 2021 5:39 PM
> *To:* Steve Magennis <steve.e.magennis@gmail.com>
> *Cc:* Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>; public-credentials <
> public-credentials@w3.org>; Naveenaa <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> wrote:
>
> At a high level, does this mol represent the primary envisioned
> interactions between Issuer, Keysmith, Holder and Verifier?
>
>
>
>
>
> 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>
> *Sent:* Thursday, May 20, 2021 10:15 PM
> *To:* steve.e.magennis@gmail.com
> *Cc:* 'public-credentials' <public-credentials@w3.org>; Naveenaa <
> 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 <steve.e.magennis@gmail.com>
> *Sent:* donderdag 20 mei 2021 16:17
> *To:* Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>; 'Luca Boldrin' <
> luca.boldrin@infocert.it>; 'Michael Herman (Trusted Digital Web)' <
> mwherman@parallelspace.net>
> *Cc:* 'public-credentials' <public-credentials@w3.org>; Kruijssen, A.
> (Age) <age.kruijssen@tno.nl>; Stornebrink, M.H.M. (Michiel) <
> 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) <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.
>
>