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