Re: [SPICE] Privacy and security by design

[Orie Steele <[e-mail]>]

inline:

On Thu, Nov 30, 2023 at 6:43 AM Denis <[e-mail]> wrote:

> Hi Orie,
>
> It took me some time to be able to find a time slot to answer to this
> email.
>
> Thanks for your review!
>
> I started a draft PR to capture your feedback here:
> https://github.com/OR13/draft-steele-spice-transparency-tokens/pull/3
>
> I was trying to build terminology from
> https://datatracker.ietf.org/doc/html/rfc4949
>
> Some of the definitions there are outdated, but some are still relevant,
> search "anonymous" for details.
>
> Inline for the rest:
>
> On Tue, Nov 28, 2023 at 11:11 AM Denis <[e-mail]> wrote:
>
>> Hi,
>>
>> This email is sent after taking a look at
>> draft-steele-transparency-tokens-latest
>>
>> The most interesting sentence of this draft is the following sentence
>> present in section 8:
>>
>>            The core operations of issuance, presentation and verification
>> must be defined in a specification
>>            with privacy and security considerations.
>>
>> However, the current content of section 9 (Security Considerations) is:
>>
>>             TODO Security
>>
>> while there is no "Privacy Considerations" section.
>>
>> It is thus proposed to identify the topics that should be addressed in
>> both the "Security Considerations" and the "Privacy Considerations"
>> sections,
>> as well as in the core of a future draft. "Privacy and security by
>> design" means identifying the properties to be met *before *starting to
>> elaborate
>> a design, a framework or an architecture.
>>
>> Before doing this, a vocabulary needs to be defined.
>>
>
> agreed.
>
>>
>> I disagree with the following definitions proposed in this draft:
>>
>>             credential:
>>             A token (usually an unforgeable data object) that is a
>> portable representation of the association between an identifier
>>             and a unit of authentication information, or statement and
>> that can be presented by a holder.
>>
>>            identifier:
>>            A data object -- often, a printable, non-blank character
>> string -- that definitively represents a specific identity of a system
>> entity,
>>            distinguishing that identity from all others.
>>
>> Associating an "identifier" and a "unit of authentication information"
>> does not make sense. When zero-knowledge proofs are being used,
>> the holder needs to demonstrate the *knowledge *of some key (secret or
>> private). There is no concept of an "identifier".
>>
>
> The proof of knowledge can itself be an identifier.
>
> There are many cases where a specific value needs to be disclosed, even if
> the subject related to that value is not consistent.
>
> Having no stable identifier for the subject, requires us to define the
> concept of an identifier, and is a precursor to a more
> precise definition of untraceability, at least that was the intent here.
>
> Your later comments on anonymous credentials also require there to be no
> "persistent recoverable identifier" from "credential proofs"... at least
> that's what I am trying to set up with this definition.
>
> [Denis] No. In all the above sentences, I disagree with the use of the
> word "identifier" . Your were referring earlier to RFC 4949. RFC 4949
> issued in 2007 is now outdated.
>
> $ credential
>       1. (I) /authentication/ "*identifier credential*": A data object
>       that is a portable representation of the association between an
>       *identifier and a unit of authentication information*, and that can
>       be presented for use in verifying an identity claimed by an entity
>       that attempts to access a system. Example: X.509 public-key
>       certificate. (See: anonymous credential.)
>
>    $ anonymous credential
>       (D) /U.S. Government/ A credential that (a) can be used to
>       authenticate a person as having a specific attribute or being a
>       member of a specific group (e.g., military veterans or U.S.
>       citizens) but (b) does not reveal the individual identity of the
>       person that presents the credential. [M0404] (See: anonymity.)
>
>       *Deprecated Term: IDOCs SHOULD NOT use this term*; it mixes concepts
>       in a potentially misleading way.
>
> However, I now understand why you used the word "identifier" which is
> fully inappropriate in the context of AnonCred.
>

[Orie] Well I still disagree... I could be proving knowledge of an
identifier, key-value pairs are "identifier-value" pairs... Semantic
precision requires them... I could go on.

Identifiers are critical, that doesn't mean they need to be mandatory or
abused.

credential
> A credential is a *set of claims about *an identity *subject.* A
> verifiable credential is a tamper-proof credential whose authorship is
> cryptographically verifiable.
> An anonymous credential, also known as AnonCreds, is a verifiable
> credential that has privacy-preserving properties to enable data
> minimization and correlation resistance.
>
> See: https://hyperledger.github.io/anoncreds-spec/
>
> I have considered these definitions and attempted to improve them.
>
>  I also disagree with the two following sections:
>
>>
>>              6.3. Credential Endorsement
>>                     Some holder's may request a counter signature on an
>> existing credential.
>>                    This can help convince a verifier who is not familiar
>> with a given issuer.
>>
>>             6.4. Presentation Notarization
>>                    Some holder's may request a receipt from a notary when
>> making presentations.
>>                    The verifier will check the signature from the issuer,
>> the signature from the holder, and evaluate the nonce
>>                    and other time related data to determine if the
>> presentation is valid.
>>
>> Since an Holder communicates directly with a verifier, these two goals
>> are out of scope. When ZKP is being used, no signature mechanism is being
>> used by the holder.
>>
> I assume you are referring to the BBS Blind Signatures draft?  -
> https://identity.foundation/bbs-signature/draft-blind-bbs-signatures.html#name-operations
>
> This document is not exclusively limited to applications of BBS.
>
> In its current form, it attempts to address SD-CWT / BBS-CWT potential
> alignment.
>
>>
>> I will now start to elaborate on the "privacy and security by design"
>> approach. However, before doing this, the vocabulary must be defined.
>>
>> We should keep three words used for identifying the three roles in Figure
>> 1 from section 1.2 "Ecosystem Overview" (non normative)
>> of "Verifiable Credentials Data Model v2.0" from W3C, i.e.; *Holder*,
>> *Issuer* and* Verifier*, but use a different wording for VC and VP.
>>
>> Thanks! This is one of the main questions I had... I am using the same
> terminology as W3C VCDM v2.0, and as
> https://datatracker.ietf.org/doc/html/rfc4949
>
> issuer, subject, holder, verifier.
>
>> In particular, a VP is an object that can contain data derived from one
>> or more credentials issued by several issuers.
>>
> Yes, W3C allows that, and does not require the collection to be secured.
>
> [Denis] I would rephrase you sentence as *VCDM 2.0 **does not explain *how
> it can be secured, but it can be done
> when using the same type of credential and when using link secrets (about
> which VCDM 2.0 is silent).
>
[Orie] That spec is very unclear, but presentations can be secured using
the same technology that issuer's use when creating the credential.

Concretely data integrity proofs, sd-jwt, and cose.... It does not say
these are the only ways to secure the JSON-LD data model, it does say a
verifiable credential is always JSON-LD.
At the request of some members of the W3C VCWG, I have been using the word
"digital credential" to make it clear I am not attempting to preserve these
limitations.


> Adding security to presentations can be complicated when the credentials
> are built on different primitives, for example a presentation of an sd-jwt
> and a jwp.
>
> [Denis] Let us first consider the cases when presentations are "built on
> the same primitives".
>
> I tend to think that addressing that layer of detail should be reserved
> for a different spec, and instead we should focus
> on the object produced by the holder upon request from a verifier... not
> the objects assembled by the holder and presented together to the verifier.
>
> [Denis] Since we should first build a framework or an architecture*s* document,
> this should be considered.
> This is easy to achieve when using blinded link secrets and link secrets.
> A verifier may want to know different attributes issued by different
> issuers.
>
> This topic also gets more complicated if we consider credential exchange
> query systems, like DIF Presentation Exchange or W3C CCG VP Request Spec.
>
> [Denis] If the templates used by the Issuer for the issued credentials are
> "similar", the Holder will easily be able to handle that information.
>

[Orie] holder's rely on application developers to create a good experience
on top of standards.
In our experience, issuers, holders and verifiers do not easily handle JSON
Schema, JSON LD, or even the technical standards.

>  The three roles are defined as follows:
>
>>       *credential holder (Holder)*
>>       owner of one or more issued credentials that can locally generate
>> a credential proof and then present it to a verifier to prove
>>       that it is the correct owner of that credential proof
>>
>>       Note to entry: in this document, a holder is an individual (i.e., a natural
>> person).
>>
>>
>> *issuing authority (Issuer)       *organization which asserts specific
>> attributes or properties about entities and delivers issued credentials
>> to credential owners
>>
>>       Note to entry: the specific attributes or properties about an
>> individual can be contained in a physical object like a passport, a driving
>> license,
>>       an ID card or can be immaterial when contained in a credential
>> placed in a digital identity wallet.
>>
>>       *credential proof verifier (Verifier)*
>>       entity attempting to verify that a credential proof is derived
>> from one or more issued credentials and whose ownership is
>> cryptographically verifiable
>>
>
> You forgot the subject... I hold vaccination credentials for my dog, but I
> am not my dog... Similarly businesses hold credentials related to their
> products, but they are not their products.
>
> [Denis] No. I didn't forget it. I dropped it. How do you prove it is *your
> *dog and not the dog of your neighbour ?  Has your dog a microchip ?
> If it has not, you have no way to prove that you hold "vaccination
> credentials" for *your *dog. It is the case,  ways already exist. Let us
> not re-invent the wheel.
> Let us keep dogs, cats, birds, rabbits, horses and "products (?)" out of
> the scope of SPICE and only consider *human-beings*.
>

I made some adjustments, based on your comments here:
https://github.com/OR13/draft-steele-spice-transparency-tokens/pull/3/commits/a8050754d087d002c25724965cc0b2d11e34e22b

[Orie] What about human beings that manage credentials related to their
children, their aging parents, and adopted adults with disabilities
(guardianship)?

These are all different subjects.

That being said, I remain uninterested in focusing exclusively on natural
persons, it is the wrong place to create focus and narrow scope.

It's also not possible to prevent the use of the technology for other
subject types, consider https://datatracker.ietf.org/wg/dult/about/

The technology does not know if it is tracking an owner's property, a
thief's stolen merchandise, or a target of gender based violence.

>
>         "On the Internet, nobody knows you're a dog" from a cartoon drawn
> by Peter Steiner, published by The New Yorker on July 5, 1993.
>
>
> A holder may have credentials related to several subjects, bound to keys
> (private or secret) under the control of the holder.
>
> [Denis]. I disagree with this statement. See above.
>
>   The objects transferred between the roles are the following:
>>
>>
>> *issued credential (IC)       *tamper-proof object that includes a set
>> of attributes about an entity issued by an issuing authority whose origin
>> is cryptographically verifiable
>>
>>
>> *anonymous credential (AC)       *issued credential that has
>> privacy-preserving properties to enable data minimization and correlation
>> resistance
>>
>>       Note to entry: also known as "AnonCreds".
>>
> I chose to avoid this term for several reasons... its marked as deprecated
> in https://datatracker.ietf.org/doc/html/rfc4949
>
> [Denis] As said earlier, RFC 4949 issued in 2007 is now outdated. The
> concept of AnonCreds did not existed at this time.
>
[Orie] It did exist (and still does), its meaning has changed. It's a good
reminder that some of the ideas from the semantic web have never worked as
advertised.

> The definition associated with "anonymous credential" was inappropriate
> and hence in 2007, the use of this term was deprecated.
>
> It's confused with blockchain projects...
> https://www.hyperledger.org/projects/anoncreds
>
> [Denis] You can use AnonCreds without using blockchains.
>
[Orie] But does this happen at scale or in practice?... The project is
still maintained by hyperledger.

> However, I really like your definition here, so I will try to square it up
> with the previous term.
>
>>       *credential proof (CP)*
>>       object derived from one or more issued credentials, constructed by
>> the owner of these credentials whose ownership is cryptographically
>> verifiable
>>
> I wonder if this is actually a better word for "presentation"... I like
> the idea of detaching the proof from the credential, and not adding a new
> term for presentation...
> because presentation implies protocol, whereas credential proof only
> implies data model.
>
> I like this suggestion, but I would prefer some symmetry between this and
> the issued credentialed.
>
> Perhaps:
>
> - proved credential
> - issued credential
>
> ?
>
> [Denis]  The word "proof" has been selected because it will fit well when
> using ZKPs and with various kinds of proofs,  e.g., of knowledge, of group
> member ship, of  non-group membership.
>
> A credential proof is not necessarily computed by the Holder using a
> single issued credential, and "proved credential" (which is in the
> singular) does not capture this possibility.
> On the contrary, a credential proof is a single data object that can be
> computed by the Holder from a several credentials issued by different
> Issuers.
>
[Orie] Based on my experience, I don't see how this is possible.
It also creates additional complexity in protocols, since the exchange
model now has extra multiplicity, the policy constraints need to account
for this, and there is a higher chance of verifier confusion.
I am not saying it cannot be done, I am saying I have never seen it done
well. Presentation Exchange in particular attempted this, and it's been one
of its most controversial features.

> Note that I have not re-used the definitions proposed in
>> draft-steele-transparency-tokens-latest, since they are not sufficiently
>> precise:
>>
>>         8.1. Issued Credential
>>
>>                This form is produced by an issuer and delivered to a
>> holder.
>>
>>        8.2. Presented Credential
>>
>>                This form is prepared by a holder and delivered to a
>> verifier.
>>                In the simple case of credentials, this form is
>> indistinguishable from the issued credential.
>>
>> When security is a concern, the last sentence above is fully wrong.
>>
>
> Again the focus of the document is not limited to BBS / ZKP.
>
> The sentence is accurate wrt the current state of the art (including the
> latest CFRG draft).
>
> [Denis] No. *When security is a concern,* this sentence is wrong :"In the
> simple case of credentials, this form is indistinguishable from the issued
> credential".
>
[Orie] No. There are cases where exclusively anonymous credentials are
simply not acceptable. Consider financial transactions / KYC.
And again, the draft you are commenting on is not exclusively limited to
anonymous credentials, if you are interested in writing a draft that is,
you are welcome to harvest any text from this document.

> The Holder needs to include either (a) a challenge received from the
> Verifier or both an identifier of the Verifier with an expiration time.
> The Holder needs to use the private key or the link secret associated with
> issued credential to perform the association.
>
>
> The sentence is not correct when considering only blind sign bbs proofs.
>
> See https://github.com/decentralized-identity/bbs-signature/issues/292
>
> These parameters are added into the header.
>
> I have not re-used either the acronym JWP (JSON Web Proof) used in
>> draft-ietf-jose-json-web-proof-01
>> since it does not allow to distinguish between the "issued form" created
>> by an issuer for a holder, and
>> the "presented form" created by a holder for a verifier. When a single
>> credential is being considered,
>> these two forms have some similarities but are fundamentally different.
>>
> I think your commentary on "credential proof" or "proved credential" is
> better, we need a terminology for this that is not locked to
> serializations.
>
>> A list of 6 privacy objectives and 8 security objectives is provided
>> below. It is not claimed that these two lists are exhaustive.
>>
>> *Privacy objectives *
>>
>>     1 Collection limitation of attributes by Verifiers
>>     2 Holder consent for sending credential proofs to verifiers
>>     3 Unlinkability of credential proofs between Verifiers
>>     4 Untrackability of a credential proof by an Issuer
>>     5 Holder observability of both issued credentials and credential
>> proofs
>>     6 Issuer anonymity among a set of Issuers
>>
>> *Security objectives *
>>
>>      1 Binding of an issued credential to the correct owner
>>      2 Verification by a Holder that an issued credential matches with an
>> expected object structure
>>      3 Verification by a Verifier that a credential proof matches with a
>> supported object structure
>>      4 Binding of a credential proof to the correct owner
>>      5 Detection of collusion attacks between individuals
>>      6 Detection of the freshness or of the validity of a credential
>> proof by a Verifier
>>      7 Binding of a credential proof to the intended verifier
>>      8 Prevention of the forwarding of a credential proof by a verifier
>> to another Verifier
>>
>> While applying these objectives, other components of the model will
>> appear.
>>
>
> I added these to the initial PR.
>
> [Denis] Thanks
>
> Denis
>
>
>> Denis
>>
>> --
>> SPICE mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spice
>>
>
>
> --
>
>
> ORIE STEELE Chief Technology Officer www.transmute.industries
>
> <https://transmute.industries>
>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>