Re: Cryptographically Enforceable Issuer Policies (forked

"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:3eebe5fb-280d-438c-8737-6b8adbbebe2a]

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<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:179918e7e914cff311]



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.