Re: [SPICE] Privacy and security by design

[Denis <[e-mail]>]

Hi Orie,

Rather than replying in-line, I copy and paste some of the text below,  
not necessarily in the same order.

====================================================================================================

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

[Denis] *I remain uninterested in focussing dogs, cats, birds, rabbits, 
horses* and "products (?)", "*credentials related to their children, 
their aging parents*, and adopted adults with disabilities 
(*guardianship*)".
*The case of natural persons is already sufficiently complicated*.

====================================================================================================

[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,

[Denis] You can prove the knowledge of any value placed in the X th 
field of an issued credential. That value may be anything and, why not 
?, an identifier. *Identifiers are NOT critical.*

====================================================================================================

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

[Denis] Currently many developers using JSON (and not using JSON Schemas 
or JSON LD) are doing everything  "manually" which is a bad practice.
              XML developers and ASN.1 developers are doing much 
better,  since they use XML Schemas and ASN.1 modules, that allow 
interoperability
             but also automatic generation and validation of objects. 
Hereafter is a good example of what ETSI is doing:

             The XML namespace URI that must be used by implementations 
of the present document is: http://uri.etsi.org/02231/v2#
              See:https://uri.etsi.org/02231/v3.1.2/ Please click on 
this link (which is an ETSI URI) and download what is there, including 
the zipped file.
             Take a look at what you got.

            This example is interesting since the same structure can be 
encoded using either ASN.1/DER or XML and a developer can get both the 
xsd file and the ASN.1 module
            and of course the specification itself. *So the developer 
can be confident that interoperability will be achieved, which 
unfortunately is not the case of several issued RFCs*.

====================================================================================================

[Orie] No. There are cases where exclusively anonymous credentials are 
simply not acceptable. Consider financial transactions / KYC.

[Denis] The concern is to *s**upport the unlinkability property *between 
Verifiers. At this time, I only know two ways to get that property:
              using either anonymous credentials or batches of "single 
use credentials" each one containing a different owner public key.

             Then after, an Holder may accept to disclose any number of 
his attributes by value or to prove a condition about them (e.g. greater 
than) by knowledge.
             This allows to support KYC.

====================================================================================================
> 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 thatcan 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 STEELEChief Technology Officerwww.transmute.industries
>>     <http://www.transmute.industries>
>>
>>     <https://transmute.industries>
>>
>
>
>
> -- 
>
>
> ORIE STEELEChief Technology Officerwww.transmute.industries
>
> <https://transmute.industries>
>