Re: Cryptographically Enforceable Issuer Policies (forked

An authorization server evaluates requests based on policies and issues
tokens that can be used to access a credential or other resource.

The important distinction is who sets the policies. The issuer, subject,
and verifier all have policies and each has the opportunity to run an
authorization server.

In cases where control must be separate from possession (a stream) or
access (such as a letter of recommendation) encryption may be used in
addition to an authorization token.

Messaging protocols consider the request as out-of-band so they do not
involve an authorization server or policy.

None of this involves governance as long as every resource and
authorization server is self-sovereign, in the sense that they own and need
not share their polices.

Adrian

On Fri, May 21, 2021 at 1:16 AM Joosten, H.J.M. (Rieks) <
rieks.joosten@tno.nl> wrote:

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