Re: [SPICE] Charter proposal for a Working Group

[Henk Birkholz <[e-mail]>]

Dear Denis,

thank you for your thoughts on charter scope and content. We think we 
incorporated some of your conceptual topics via the response to Roman's 
charter review. Please find detailed replies in-line.


Viele Grüße,

Orie & Henk

On 14.10.23 16:06, Denis wrote:
> 
> Below is a new charter proposal constructed along three sections:
> 
> - Background,
>      - Goals,
>      - Program of Work.
> 
> It is an incomplete proposal, since it does not include a section about 
> milestones.
> 
> It uses the following terminology:
> 
>        - "digital credential" which is equivalent to "VC" in the VCDM2.0 
> from W3C (with a definition of this wording).

We adopted this language and provided a definition in response to 
Roman's feedback.

> 
>        - "proof token" which is equivalent to "VP" in the VCDM 2.0 from 
> W3C (with an explanation of this wording).

We comment of JWP / JWT / CWT when discussing the use of existing IETF 
work in the current charter version.

> 
> 
> *Charter for Working Group *
> 
> *Background*
> 
> Wallets are resident applications placed in a smart phones. They are 
> already in use today, mostly for payments purposes,
> with smart phones equipped with NFC (Near-field communication). NFC 
> allows wallets to be used either in an offline
> or an online mode. Their usage is currently being expended to support 
> digital credentials intended to be used both
> in the public and private sectors.

We don't think that end user devices or platform specific details are 
necessary to address the architectural design goals of digital credentials.

> 
> In this kind of environments, a "three roles model" is considered. It 
> involves: an Holder, an Issuer and a Verifier.
> An Issuer delivers to a user (i.e. an individual) upon his request one 
> or more digital credentials.
> 
> A digital credential is a set of tamper-evident claims and metadata that 
> cryptographically prove who issued it.

We call this out as a desired property of digital credentials in the 
current charter, among others.

> 
> When a user has gotten a digital credential, then he becomes a Holder. 
> An Holder that has received one or more digital
> credentialsfrom one or more Issuers places them into a wallet, 
> associated with one or more cryptographic keys.
> 
> An Holder transforms one or more digital credentials into a proof token 
> which is then presented to a Verifier
> which is usually a service or a goods provider.

RES: This will likely need to be addressed in the architecture document, 
we think the current charter text is consistent with your suggestion.

> 
> Different actors are already working on this topic, in particular W3C 
> which has specified a "Verifiable Credential Data Model"
> VCDM 2.0. This year, the EU has launched various experiments before the 
> issuance of a final version of the eIDAS 2.0 Regulation.

We removed some commentary on this topic at Roman's request.

> 
> *Goals*
> 
> Some verifiers may require the disclosure of more personal information 
> than strictly necessary in order to allow a user
> to perform a given action. It is intended to help users to select and 
> give their consent about the personal data
> they wish to disclose to a verifier, using a digital credential format, 
> a proof token format and a protocol that the verifier
> and the wallet jointly support.

Agreed, topics such as this will have to be addressed in the privacy / 
security considerations sections of the architecture document.

> 
> While a digital credential contains a set of claims about a user, the 
> wallet should be able to selectively disclose
> a subset of these claims and obtain the user consent before building and 
> sending a proof token to a Verifier.

Same comment regarding the architecture document, we don't think this 
level of detail is appropriate for the charter.

> 
> Claims may be general claims such as : given_name, family_name, 
> middle_name, nickname, preferred_username, email, email_verified,
> gender, birthdate, phone_number, phone_number_verified, address, but may 
> also be sector specific, e.g. for healthcare or education,
> or professional claims like professional qualifications or positions in 
> a company like roles or group memberships. It is intended
> to allow the inclusion of sector specific claims into a digital 
> credential but to let external actors specifying them.
> A goal is to be able to use digital credentials both for C to B and B to B.

This seems to be questioning how private claims vs. registered claims 
function. Addressing this is a goal of the architecture document.

> 
> A concern is whether different Verifiers will be able to link the proof 
> tokens they receive to the same user.
> While such linkage may be desirable between servers belonging to the 
> public sector, it may not be desirable for the private sector.

This is verifier / verifier unlinkability, its best commented on here: 
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/354

> 
> One goal of the work is to be able to support both cases, i.e., either 
> unlinkability or linkability. The revocation of digital credentials
> will be considered for both cases: when supporting the unlinkability 
> property and when not supporting it.

Agreed. See the OAUTH definition in the link above, which we feel is 
state-of-the-art at this time.

> 
> An important use case is to be able to demonstrate that a user is above 
> an age limit without disclosing his date of birth,
> nor its age, nor one or more claims that would allow verifiers to link 
> user accounts. In this use case, it is necessary to prevent
> collaborative attacks between users, e.g., where Bob who is 25 would 
> transfer to Alice who is 12 a proof token demonstrating
> that he is over 18 and, as a result, Alice would be able to fool a 
> Verifier by demonstrating that she is over 18.
> This security issue will be addressed.

This is too much detail for a charter, but could be addressed in the 
architecture document to some extent, potentially.

> 
> Proof tokens may use either asymmetric cryptography or zero-knowledge 
> proofs (ZKPs). One goal is to allow a co-existence
> of asymmetric cryptography with ZKPs as well as a smooth transition from 
> asymmetric cryptography to ZKPs.
> 
> While ZKPs allow to support selective disclosure and (if properly used) 
> the unlinkability property, they allow a wide range
> of possibilities, e.g., to proof of knowledge of something without 
> revealing the something (e.g. a signature value),
> to support predicates that allow verifiers to check a claim value 
> against a certain condition without disclosing the value of the claim,
> to check whether a claim value is either a member of a set of values or 
> is not a member of a set of values without disclosing
> the value of the claim. One goal is to be able to support such kinds of 
> ZKPs.

Agreed, but again too much detail on the solution and we have included 
relevant references in the current revised charter text.

> 
> *Program of Work*
> 
> The WG is expected to develop:
> 
> (1) A framework for the three-roles model (i.e., Holder, Issuer and 
> Verifier) and additional components for the support
>      of this model in the context of digital identity wallets (as an 
> informational document).
> _
> _ _Note_: The framework will allow to define and stabilize the 
> vocabulary and to identify which interactions may take place
>            between the components and which kind of metadata should be 
> made available by Issuers and Verifiers.
>            The Framework will not define the syntaxes to be used.

Yes, we feel the architecture document will do this, while also defining 
the desired properties of digital credentials.

> 
> (2) Standard Track documents to define one or more digital credential 
> formats and their associated cryptographic keys.
> 
> _Note_: It is possible that a format able to natively support the 
> unlinkability property will be different from
>             another one that does not natively support the unlinkability 
> property.

Yes. See revised milestones.

> 
> (3) A Standards Track document for protocols allowing a candidate-Holder 
> to request to an Issuer a certain digital credential
>      using a wallet and then to receive it so that it can be stored into 
> the wallet and associated with a cryptographic key.
> 
> _Note_: EAT (Entity Attestation Token) developed by the RATS WG 
> (draft-ietf-rats-eat) is likely to be a candidate
>             to be used within this protocol.

No. See the desire to keep protocols out.

> 
> (4) Standards Track document(s) specifying Metadata associated with 
> Issuers and Verifiers.
> 
> _Note_: Metadata associated with Verifiers may be made public or only be 
> made available at the time of an action
>            that an Holder is willing to perform on a Verifier.

Yes. See the identity document proposal in current charter work items / 
milestones.

> 
> (5) Standards Track document(s) for allowing an Holder to build a Proof 
> Token from one or more digital credentials
>      and then to communicate it to a Verifier.

Yes. See revised milestones.

> 
> (6) Guidance for the revocation of Credentials while supporting or not 
> the unlinkability property between verifiers
>      (as an informational document).

Yes, although this is probably best addressed in architecture and then 
referenced from the "token formats" Internet-Drafts, to comment on the 
Issuer/Verifier vs Verifier/Verifier implications, also coordination 
OAUTH which has adopted status list mechanisms that might be used with 
the other work items adopted by OAUTH.


> _
> _ _Note 1_: It is anticipated that the support of the unlinkability 
> between verifiers will mandate specific characteristics
>              for both the wallet and the smartphone used by the Holder 
> which are wallet, RichOS and device specific.
> 
> _Note 2_: It is anticipated that the status_list extension draft from 
> the OAuth WG will be usable when the unlinkability
>              property is not required.
> 
> An informal goal of the working group is close coordination with the 
> JOSE WG, OAuth WG, OpenID Connect and the IRTF CFRG
> that has made available a draft on BBS+ signatures 
> (draft-irtf-cfrg-bbs-signatures-latest)

Yes, we believe this is reflected in the current text.

> 
> Denis
> 
> 
>