[SPICE] The Credentials Framework 1.0

[Denis <[e-mail]>]

Hi  Orie,

I changed the header of this thread, but its content is a response to 
your previous email.

Thank you for your detailed response. I am amazed by the time you spend 
and have spent on various forums.
I don't have the time available to participate to such numbers of WGs or 
forums.
> The reason I shared the repo links was for context on how other people 
> see the problem space (particularly browser vendors who are designing 
> APIs that are relevant to your proposal).
>
> You may feel OAUTH is not a solution, I'm not here to convince you 
> that it's the only way to do things, just that it's a way to do things 
> that other people seem to agree with:
>
> https://github.com/WICG/identity-credential/issues/14

[Denis]

"When the only tool you have is a hammer (i.e. a JWT), every problem 
looks like a nail".    :-)
Whenever user authentication to an HTTPS server is sufficient to address 
the problem to be solved, it should be used.
Why do things complicated when they can be simple and more flexible ?

> I fear that you are proposing a tiny group of people redo a bunch of 
> work that has already been successfully started and is currently being 
> tackled elsewhere(s).

[Denis]

When taking a look at the email exchanges, it looks like the group is 
indeed tiny since it seems that we are the only persons exchanging emails.
I believed that one goal of the SPICE BoF is to identify and to attempt 
to federate different initiatives discussed elsewhere, not necessarily 
only within the IETF.

> OAUTH frequently discusses issues related to OpenID Connect and 
> authentication and authorization, see this recent review,
> as one example of the kind of review you might get on your proposal 
> were it in draft form:
>
> https://mailarchive.ietf.org/arch/msg/oauth/fWrIsOfw-iJBD0867NO8nkPqaUo/
>
> I feel you will get better feedback regarding your comment on the 
> OAUTH list.

[Denis]

I am on the OAuth WG list and I saw the response from Justin.
I sent a few messages on the OAuth mailing list about" OAuth and JWT/VC 
documents".
See: 
https://mailarchive.ietf.org/arch/msg/oauth/-ob2fqU1_OEwZuUU8KheEuEuv2s/
and also: 
https://mailarchive.ietf.org/arch/msg/oauth/Rg8l_aKdvogr8udewODs8-mkcKA/

> Of course IETF business is conducted on lists, hence my response to 
> your suggestions, on this list.
>
> Maybe schemas are needed when transforming an existing media type, 
> into a secured format and back, while leveraging ZKPs....
> but all the discussion regarding this topic in the context of JWP, 
> would probably be better addressed in the working group that adopted JWP.
>
> There was some discussion of the schema / transformation a while back:
>
> https://github.com/json-web-proofs/json-web-proofs/issues/4
> https://github.com/json-web-proofs/json-web-proofs/issues/33#issuecomment-993870581
>
> ^ This last issue directly addresses your comment, regarding the need 
> to transform media types prior to using them with ZKPs.

[Denis]

The more I think, the more I believe that a Credential Framework should 
be the first deliverable.
Such a framework will at the same time identify which topics will need 
to be standardized.
A concern I have with the OAuth WG is that numerous draft proposals 
(around 50) have been made during more than 10 years without being 
planed ahead.

> Again, I suggest you might get better comments on JWP topics on the 
> JOSE list, I am not sure how familiar with the details folks on this 
> list are (and there are a lot less people on this list).
>
> So far, you and I seem to be the only people discussing JWP and OAUTH 
> on this list, which might indicate that this list isn't the best place 
> to get critical feedback on these topics.
>
> I believe that some schema tooling, similar to what EAT uses, might be 
> helpful in aligning COSE and JOSE architecturally.
>
> But whether that's value that is just for the spec readers, or if it 
> is required by implementers remains to be seen.
>
> As you said in your earlier message, folks from RATs might be better 
> able to comment on if CDDL or some other tooling used by EAT could 
> help preserve architectural alignment.

[Denis]

In the context of ZKP, the goal for a Verifier is to able to understand 
if the data structure (i.e. a "Proof" rather than a "Token" ) it receives
complies with a Credential schema that it supports and then to relate 
each index in front of a byte string to one or more (personal data) 
claim names.
CDDL is not designed for that purpose.

> I think it's worth exploring how we might address "credential schemas" 
> without fixing the claims format to JSON or CBOR, and while reusing 
> other IETF work.

[Denis]

I agree on the first part of this sentence, but I have reservations on 
the last part, i.e.,  "while reusing other IETF work". It looks like a 
NIH syndrome (Not Invented Here).

Anyway, it is important to recall one of my email sent on the OAuth 
mailing list and referenced earlier in this email:

       Below is an answer to the second question raised by Roman:

    *       What needs to be done first? **
    *

         1) A Framework, usable in a smartphone environment, needs first 
to be defined with its own vocabulary and its own data flows.
             Let us call it something like: "*The Credentials Framework 
1.0*".

Denis

>
> OS
>
>
> On Tue, Oct 10, 2023 at 1:51 PM Denis <[e-mail]> wrote:
>
>     Hi  Orie,
>
>     Inline:
>
>>     Inline:
>>
>>     On Tue, Oct 10, 2023 at 11:32 AM Denis <[e-mail]> wrote:
>>
>>         *About the Credential request*
>>
>>         This email is a continuation of a previous email called:
>>         "Walk-through before the sending of a Credential request".
>>
>>         In an attempt to place all currently known mechanisms under
>>         the same umbrella, the following description focuses
>>         on the Credential request. The response to this request is
>>         not (yet) described.
>>
>>         *Foreword*: The following approach is rather different from
>>         the approach described in OpenID for Verifiable Credential
>>         Issuance
>>                      
>>         (https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html).
>>
>>         Before the sending of a Credential request to an Issuer by an
>>         individual (at this time not yet a Holder but only a
>>         candidate-Holder),
>>         it is assumed that several exchanges have taken place, first
>>         between the candidate-Holder and the Verifier and then between
>>         the candidate-Holder and the Issuer. At the end of these
>>         exchanges, both the candidate-Holder and the Issuer have
>>         agreed on the content
>>         of the Credential and some associated characteristics, e.g.,
>>         using some forms.
>>
>>         In the last exchange between the candidate-Holder and the
>>         Issuer, the Issuer has communicated to the candidate-Holder
>>         a challenge or a nonce, and a reference to a form that has
>>         been completed:
>>
>>              - the challenge or the nonce will be used to detect
>>         replay attacks,
>>
>>              - a reference to a completed form, so that this
>>         reference may be used later on
>>                (e.g., to renew one Credential or to re-issue several
>>         Credentials).
>>
>>     You are describing an authentication protocol, this seems like a
>>     discussion better supported by the OAUTH list.
>
>     [Denis]
>
>     Not really. OAuth is not supporting authentication protocols but
>     AUTHORIZATION protocols.
>     An AUTHORIZATION protocol is not needed in this context.
>
>>     I grant that "W3C Verifiable Presentations" mixed some elements
>>     of authentication and key discovery with their data model
>>     definition work.
>>     The result has been that "W3C Verifiable Presentations" are
>>     basically whatever JSON-LD you want them to be...
>>     and there is nearly no interop across presentations of different
>>     credential formats.
>
>     [Denis]
>
>     I was not talking at any moment in this email of "W3C Verifiable
>     Presentations", nor JSON-LD, so your comment is not relevant to
>     the content of this email/./
>
>>     This seems better tackled on the OAUTH list or in the WICG;
>>
>>     - https://github.com/WICG/identity-credential/issues
>>     - https://github.com/oauth-wg/oauth-sd-jwt-vc/issues
>
>     [Denis]
>
>     The IETF rules is to have discussions on mailing lists , i.e., 
>     not on github .
>
>     If you believe that some other work may be of interest to the
>     SPICE BoF, you may provide detailed contributions to the SPICE
>     mailing list
>     (and not simply links).
>
>>         Hence in the Credential request, the candidate-Holder does
>>         not need to include any kind of data structure
>>         (e.g., using JSON or JSON-LD) that would looks like a
>>         completed credential template.
>>
>>         Based on previous exchanges, the Issuer also indicates to the
>>         candidate-Holder whether :
>>
>>             - (asymmetric) key pairs should be generated (and if so,
>>         how many) or
>>
>>             - a single link secret should be generated (unless it has
>>         already been generated).
>>
>>     https://github.com/json-web-proofs/json-web-proofs/issues
>>     <https://github.com/json-web-proofs/json-web-proofs/issues>
>>
>>     Not all schemes will support linked secrets / unlinkability,
>>     those that do will need to mature further before we can use them
>>     consistently in both JOSE and COSE.
>
>     [Denis]
>
>     The proposal explores three alternatives.  link secret /
>     unlinkability is one only of them. Unlinkability may also be
>     obtained using the second case, i.e., using *several key pairs*.
>
>     In order to allow a smooth transition, we need to consider the
>     whole picture and not only selective disclosure using a JSON object.
>
>>         The goal of the following analysis is to detail the
>>         commonalities and the differences between the use
>>         of a single key pair, several key pairs or a single link secret.
>>         *
>>         **Use of a single key pair:
>>         *
>>            - since the public key can be used as a link across
>>         different verifiers, this use case does not allow to support
>>         the unlinkability property
>>              between verifiers.
>>
>>            - if the private key cannot be extracted or read outside
>>         of a given device and if the disclosed claims allow to
>>         uniquely identify the individual
>>              across several verifiers, then the detection of
>>         collaborative attacks against a verifier is not required.
>>
>>
>>     I'm not sure preventing *collusion of verifiers* is a design
>>     goal, there does not seem to be consensus that this is a
>>     requirement, based on the meetings I have been in.
>     [Denis]
>
>     Do you really want all the verifiers (i.e., servers) around the
>     world to be able to establish links between their user accounts
>     /without any error possible /?
>
>     This is first a privacy and a societal concern.
>>
>>         Note 1: It is required to demonstrate that the private key
>>         cannot be extracted or read outside of a given device and
>>                 that the Credential request includes the challenge
>>         and a reference to a completed form received from the issuer,
>>                 a public key and a digital signature over the
>>         Credential request using the private key hosted by the given
>>         device.
>>
>>         Note 2: The use of an Entity Attestation Token (EAT) i.e.,
>>         draft-ietf-rats-eat-21 in association with "EAT Media Types",
>>                 i.e., draft-ietf-rats-eat-media-type-02, allows to
>>         inform a Relying Party about the characteristics of the
>>         environment of an application
>>                 which might be useful in the future, but currently
>>         omits to consider that it is possible/useful to be confident
>>         that some requests
>>                 (i.e. the Credential(s) request in this case) are
>>         indeed coming from an "entity" that complies with the
>>         characteristics of the environment.
>>                 See Note 6 for further details.
>>
>>         *Use of several key pairs:
>>         *
>>            - this use case allows to support the unlinkability
>>         property between verifiers, if both a different key pair is
>>         used for each verifier
>>              and the "Proof Token" does not contain a claim that
>>         allows to uniquely identify the token across several
>>         verifiers e.g., a "status_list" claim.
>>
>>            - if the private key cannot be extracted or read outside
>>         of a given device and if the disclosed claims allow to
>>         uniquely identify the individual
>>              across several verifiers, then the detection of
>>         collaborative attacks against a verifier is not required.
>>
>>         Note 3: It is required to demonstrate that each private key
>>         cannot be extracted or read outside of a given device and
>>         that the Credential request
>>                 includes, */for each key pair/*, the challenge and
>>         the reference to a completed form received from the issuer, a
>>         public key and a digital signature
>>                 over the Credential request using each private key
>>         hosted by the given device.
>>         *
>>         *
>>
>>     Same comment as above regarding unlinkability being a "nice to
>>     have", not a requirement.... and also being worked on in JOSE
>>     already.
>
>     [Denis] Same as above: This is a privacy and a societal concern.
>     From the few information I have been able to obtain from the
>     experiments undertaken by the EC about the EU digital identity wallet,
>     such linkage will be "built-in" ...  but this has not been
>     advertised.
>
>>         ***Use of a single link secret:
>>         *
>>            (a)  this use case allows to support the unlinkability
>>         property between verifiers, if the "Proof Token" does not
>>         contain
>>                 a claim that allows to uniquely identify the token
>>         across several verifiers e.g., a "status_list" claim.
>>
>>            (b) if the disclosed claims allow to uniquely identify the
>>         individual across several verifiers, then the detection of
>>         collaborative attacks
>>                against a verifier is not required.
>>
>>            (c) if the disclosed claims do not allow to uniquely
>>         identify the individual across several verifiers, then the
>>         detection of collaborative attacks
>>                against a verifier is required.
>>
>>         Note 4: In case (b), it is sufficient to demonstrate that the
>>         secret link cannot be extracted or read outside of a given
>>         device and
>>                 that the Credential request includes the challenge
>>         and the reference to a completed form received from the
>>         issuer, a blinded link secret,
>>                 a proof of knowledge of the link secret corresponding
>>         to the blinded link secret and a zero-knowledge proof of
>>         knowledge
>>                 over the Credential request using the link secret
>>         hosted by the given device.
>>
>>         Note 5: In case (c), it is necessary to demonstrate that the
>>         link secret is under the control of a given TA (Trusted
>>         Application)
>>                 supported by a given TEE (Trusted Execution
>>         Environment) on a given device and that the Credential
>>         request includes the challenge
>>                 and the reference to a completed form received from
>>         the issuer, a blinded link secret, a proof of knowledge of
>>         the link secret
>>                 corresponding to the blinded link secret and a
>>         zero-knowledge proof of knowledge over the Credential request
>>         using the link secret
>>                 hosted by the given device.
>>
>>         Note 6: The use of an Entity Attestation Token (EAT) i.e.,
>>         draft-ietf-rats-eat-21 in association with "EAT Media Types",
>>                 i.e., draft-ietf-rats-eat-media-type-02, allows to
>>         inform a Relying Party about the characteristics of a wallet.
>>                 Since there already exist proprietary implementations
>>         of the concepts described in RFC 9334 (i.e., Remote
>>         ATtestation procedureS (RATS) Architecture)
>>                 the use of Entity Attestation Tokens (EATs) might be
>>         useful in the future to facilitate the tasks undertaken by
>>         Issuers
>>                 (if some major players accept to implement it). Note
>>         that the previous description is not dependant upon the use
>>         of EAT.
>>
>>
>>         Section 9.3 of draft-ietf-rats-eat (Freshness) mentions:
>>
>>                  All EAT use MUST provide a freshness mechanism to
>>         prevent replay and related attacks. The extensive discussions
>>         on freshness
>>                  in [RATS.Architecture] including security
>>         considerations apply here. The EAT nonce claim, in Section
>>         4.1, is one option to provide freshness.
>>
>>         This is true, however another important security
>>         consideration is missing: Message authentication.
>>         *
>>            Message authentication*
>>
>>              EAT MAY support a message authentication mechanism, if a
>>         hash (i.e., a hash algo. identifier and a hash value) is
>>         included
>>              along with the Claims in the Evidence and hence is also
>>         signed. This allows to make sure that a request has indeed be
>>         generated
>>              by the right "entity".
>>
>>         Since Henk and Hannes are both members of the SPICE BoF and
>>         of the RATS WG, they might consider to propose an addition to
>>         the current draft.
>>
>>
>>     I think a narrow charter focused on ensuring "credential
>>     architectural alignment between JOSE and COSE" is more than
>>     enough work... and developing new algorithms or protocols should
>>     be done in the working groups best suited to comment on relevant
>>     design considerations... It could be that SD-CWT is better done
>>     by OAUTH  because SD-JWT was done by OAUTH... similar to the work
>>     happening in JOSE, I'd be cautious attempting to generalize salt
>>     / nonce based message authentication schemes at SPICE... but
>>     there is some overlap is design between what you are talking
>>     about here, and the construction of SD-JWT and SD-CWT.
>
>     [Denis] You are only focussing on a data structure description in
>     particular on SD-JWT.
>     I am focussing on the whole architecture to better understand the
>     needs, in particular *to allow a smooth transition in the future
>     to the use of ZKPs*, e.g., using BBS or BBS+.
>     With such technique, a data serialization is needed since ZKPs use
>     numbers instead of character strings. *Credential schemas *are
>     necessary to be able to use ZKPs.
>
>     Note: I know that JSON can be used without using schemas, but
>     instead of coding by hand each use case, the use of schemas allows
>     to automate controls.
>
>     I have started with two descriptions. Additional descriptions will
>     be needed:
>
>         1° An enquiry made by a Verifier to obtain information made
>         available by Issuer(s) to take a decision about which
>         Issuer(s) it can trust
>            and which *credential **schemas* it may need to support.
>
>         2° A Holder - Verifier dialogue where the Holder needs to know
>         which Issuers are trusted by a given Verifier and which data
>         format(s)
>             will be accepted by that Verifier when later on the Holder
>         will derive Presentation data from one or more of his credentials.
>
>         3° The response to a Credential request, so that the requested
>         credential can be stored in the wallet associated together with
>              its**associated *credential **schema*.
>
>         4° A Holder - Verifier dialogue where the Holder derives
>         Presentation data from one or more of his credentials
>             using its associated *credential **schema*.
>
>     Before proposing solutions, we need to understand what the
>     problems to be solved are.
>
>     Denis
>
>
>>         Denis
>>
>>         PS. The content of this email is proposed to be discussed
>>         during the next SPICE meeting on Thursday 12 th.
>>
>>
>>
>>
>>         -- 
>>         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>
>