RE: Cryptographically Enforceable Issuer Policies (forked

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 <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

 <mailto:rieks.joosten@tno.nl> @Joosten, H.J.M. (Rieks), 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.