Re: Cryptographically Enforceable Issuer Policies (forked

Hi David,

You seem to be missing the difference between identifiers and identity.
DIDs are self-sovereign (self-verifying) identifiers. They intentionally,
for privacy reasons that are well-discussed and documented, try to make no
claims to identity. DIDs are more or less public and "out of control" in
the sense that public keys are public.

VCs are also self-sovereign (self-verifying) identity-related claims. VCs
are meant to be shared to support identity but they are meant to be shared
with control by the subject. VCs are self-sovereign in the sense that
clothing is self-sovereign.

When it comes to protocols for presenting "papers please", discount
coupons, prescriptions, or letters of recommendation the subject is NEVER
self-sovereign and the only control the subject has over the presentation
is what is built-in to the protocol itself. For example, the protocol at
the bar does not "call home" to check your identity but the protocol for
the policeman definitely calls home from their cruiser before returning
your license back to you.

DIDs and VCs are merely self-certifying data models carefully designed to
support all sorts of protocols. On top of the standards, the SSI community
is discussing data models for requesting presentations and tokens. We also
discuss data models for tokens including some that are capabilities like
macaroons, bisquits, and zcap-ld. All of these data models can support all
sorts of protocols for transport-level, message-level, and authorization
security.

Let's not confuse the security of protocols with their privacy or identity
aspects.

Our work is not necessary for supermarket discount coupons because they
have no need for identity.

Adrian

On Sat, May 22, 2021 at 6:16 AM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:

> Hi Rieks
>
> this is very interesting model and goes completely against the existing
> real life model that is ubiquitously in use today with physical credentials
> viz: the issuer issues a plastic/paper credential to a holder, and the
> holder can show it to whoever she/he pleases whenever she/he wants to. A
> verifier can accept any plastic/paper credential regardless of the terms of
> use printed on it by the issuer. The issuer has no control over this
> presentation.
>
> A common use case of this model is a supermarket that issues a money-off
> coupon that states 'only to be accepted by this supermarket'. A rival
> supermarket accepts the coupon and gives the customer the same money off,
> so as to get the customer's business. The rival supermarket absorbs this
> cost and the issuing supermarket has no control over this.
>
> As I understand your model, the issuer can now exert full control over who
> the holder is able to effectively give the credential to, because only
> authorised verifiers will be able to decrypt the credential. As you say,
> this is a useful addition to the existing physical credential model, and I
> can imagine that some issuers will want to exert total control over "their"
> credentials. Of course this is the final nail in the coffin of the SSI
> myth, as users never were self-sovereign over their credentials. Issuers
> always had total control over who to issue their credentials to, and when
> to revoke them from the holders. The only self-sovereign aspect that users
> had prior to your model, was control over who to present their credentials
> to. Your model now removes this final aspect of control from them as well.
> I dont know whether to say 'well done' or 'how sad'.
>
> Kind regards
>
> David
>
>
> On 22/05/2021 10:11, Joosten, H.J.M. (Rieks) wrote:
>
> CAUTION: This email originated from outside of the organisation. Do not
> click links or open attachments unless you recognise the sender and know
> the content is safe.
>
> 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> <agropper@healthurl.com>
> *Sent:* zaterdag 22 mei 2021 09:12
> *To:* Jim St.Clair <jim.stclair@lumedic.io> <jim.stclair@lumedic.io>
> *Cc:* Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>
> <rieks.joosten@tno.nl>; Naveenaa <n.a.karthikeyan@student.utwente.nl>
> <n.a.karthikeyan@student.utwente.nl>; Steve Magennis
> <steve.e.magennis@gmail.com> <steve.e.magennis@gmail.com>;
> public-credentials <public-credentials@w3.org> <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.
>
>