RE: Cryptographically Enforceable Issuer Policies (forked

Mmmm Crypto magic!

 

 

 

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

 

 <mailto:steve.e.magennis@gmail.com> @steve.e.magennis@gmail.com: I’ll leave most responses to the upcoming paper. However:

* Regarding your “How can a KeySmith validate a supplied attribute without knowing what attributes a policy requires”: to me, ‘validation’ is the process that a party uses to determine whether or not that data is valid to be used for some specific purpose(s) of that party. Typically, “some specific purpose” would be ‘to be used as a value (for a variable) in an argument that, when evaluated, leads to a decision’, such as an access control decision, or a commitment decision for a transaction. The KeySmith needs to validate attributes for the purpose of determining whether or not to provide the verifier with a decryption key. This is not the same as validating these attributes for determining whether or not the verifier satisfies the issuers policy, but they are related (of course), which the paper will explain.
* Regarding your “what does the mechanism look like that allows a would-be Verifier to be permitted / denied the ability to decrypt a credential based on additional policy requirements imposed by an issuer?”: This is all in the CP-ABE crypto-magic. My understanding is that a verifier that wants to be able to decrypt [[plaintext + issuer-policy]]pk will need to request a decryption key from the KeySmith associated with pk. This request contains attributes (of the verifier), that the KeySmith uses to construct a decryption key DKattrs which it returns to the verifier. This DKattrs has the ‘CP-ABE cryptomagical’ property that decryption of [[plaintext + issuer-policy]]pk only succeeds if the attributes used to construct Dkattrs satisfy the issuer-policy. This is all data and math. What is also needed is that the meaning of the attributes and the truthvulness of the statements they represent is established, and the math will actually represent a valid reasoning argument. This implies two things: 

* The decision of the KeySmith whether or not to issue a DK must be based on a criterion C that uses these attributes, as well as criteria by which it can determine whether or not the individual attributes are valid to be used as values for evaluating C. For any PK for which the KeySmith accepts DK-generation requests, it must publish both C and the other criteria.
* The issuer should only use a PK of some KeySmith for encrypting ‘plaintext + issuer-policy’ after it has determined that: 

* ‘issuer-policy’ only uses attribute-types that the KeySmith requires from requesters that request a DK that is associated with PK;
* the criteria that the KeySmith uses to validate verifier-attributes for its decision to generate a DK imply that these verifier-attributes are also valid for evaluating the issuer policy.

because only then will the math of the crypto-magic map onto the meaning as the issuer intended.

I’ll leave it at this. 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: zaterdag 22 mei 2021 16:20
To: 'Adrian Gropper' <agropper@healthurl.com <mailto:agropper@healthurl.com> >; Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl <mailto:rieks.joosten@tno.nl> >
Cc: 'Jim St.Clair' <jim.stclair@lumedic.io <mailto:jim.stclair@lumedic.io> >; 'Naveenaa' <n.a.karthikeyan@student.utwente.nl <mailto:n.a.karthikeyan@student.utwente.nl> >; 'public-credentials' <public-credentials@w3.org <mailto:public-credentials@w3.org> >
Subject: RE: Cryptographically Enforceable Issuer Policies (forked

 

[sm:] comments inline and thanks, I’m looking forward to learning more!

 

From: Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com> > 
Sent: Saturday, May 22, 2021 5:45 AM
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl <mailto:rieks.joosten@tno.nl> >
Cc: Steve Magennis <steve.e.magennis@gmail.com <mailto:steve.e.magennis@gmail.com> >; Jim St.Clair <jim.stclair@lumedic.io <mailto:jim.stclair@lumedic.io> >; Naveenaa <n.a.karthikeyan@student.utwente.nl <mailto:n.a.karthikeyan@student.utwente.nl> >; public-credentials <public-credentials@w3.org <mailto:public-credentials@w3.org> >
Subject: 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 <mailto: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.

 

 <mailto:steve.e.magennis@gmail.com> @Steve Magennis: 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?

[sm]: I thought that it would be strange for an issuer to hand policy information over to a KeySmith, but that leaves me confused on two points. First In your earlier email you said: 

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.

How can a KeySmith validate a supplied attribute without knowing what attributes a policy requires? Secondly and back to my original question, what does the mechanism look like that allows a would-be Verifier to be permitted / denied the ability to decrypt a credential based on additional policy requirements imposed by an issuer? Does this imply adopting some sort of structured policy language and evaluation engine (possibly polymorphic). Would some / all of this stuff be baked into the encrypted credential itself?

I used good old PowerPoint for the graphic. 😊

 <mailto:agropper@healthurl.com> @Adrian Gropper: 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.


 <mailto:agropper@healthurl.com> @Adrian Gropper: 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.

 

 <mailto:steve.e.magennis@gmail.com> @Steve Magennis: 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.

[sm]: This is interesting, I look forward to a deeper analysis.

 

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

_______________ 

 

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? 

 



 

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

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