Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)

[Denis <[e-mail]>]

Hi Giuseppe,
> Ciao Denis,
>
> Thank you! By points.

First, I still have a vocabulary problem. The text states:

    A *digital credential* may be presented to a verifier long after it
    has been issued.

It should rather say: A *digital proof *(derived from a digital 
credential) may be presented to a verifier.

Then, the text states:

    Verifier:

        Entity that relies on the validity of the Digital Credentials
        presented to it.

I should rather say:

         Verifier:

               Entity that relies on the validity of the *digital proof*
    presented to it.

>
> OAuth Status List can be accessed by a Verifier when an internet 
> connection is present.
>
>  *
>     This does not correspond to the flows of the figure.
>
>
> the section enumerates the differences between oauth status list and 
> oauth status attestations.
> The subject of the sentence is then the oauth status list, below I 
> report the original text in that point:
>
> *Offline flow*: OAuth Status List can be accessed by a Verifier when 
> an internet connection is present. At the same time, OAuth Status List 
> defines how to provide a static Status List Token, to be included 
> within a Digital Credential. This requires the Wallet Instance to 
> acquire a new Digital Credential for a specific presentation. Even if 
> similar to the OAuth Status List Token, the Status Attestations enable 
> the User to persistently use their preexistent Digital Credentials, as 
> long as the linked Status Attestation is available and presented to 
> the Verifier, and not expired.

  OK.

>
>   * What about the support of "blinded link secrets" and "link
>     secrets" (used with anonymous credentials) ?
>
>
> Unfortunately I don't have these in the EUDI ARF and in my 
> implementative asset but this doesn't prevent us to not include it in 
> the draft.

When writing this, I had the use case of BBS+ in mind.

Published versions of the ARF is available here: 
https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/arf.md 


The word "privacy" is used once in a single sentence copied below which is:

    Attestation exchange Protocol. This protocol defines how to request
    and present the PID and the (Q)EAA in a secure and *privacy*
    preserving fashion.

In the context of a single data controller, ISO 29100 identifies eleven 
privacy principles:

    1.   Consent and choice
    2.   Purpose legitimacy and specification
    3.   Collection limitation
    4.   Data minimization
    5.   Use, retention and disclosure limitation
    6.   Accuracy and quality
    7.   Openness, transparency and notice
    8.   Individual participation and access
    9.   Accountability
    10. Information security
    11. Privacy compliance

None of them is being addressed.

In addition, when considering a distributed system used by human beings, 
*two additional **privacy principles *need to be taken into consideration
and none of them is mentioned:

*      Unlinkability *of holders between verifiers

*      Untrackability* of holders by a server, (i.e., a property 
ensuring that it is not possible for a server to know by which verifier 
the information it issues to a caller,
                                 or derivations from it, will be 
consumed. In other words : Can the server act as Big Brother ?

Margrethe*Vestager*, [former] Executive Vice-President for a Europe Fit 
for the Digital Age said:

/      “The European digital identity will enable us to do in any Member 
State as we do at home without any extra cost and fewer hurdles. /
/      Be that renting a flat or opening a bank account outside of our 
home country. And do this in a way that is secure and transparent. /
/*S**o that we will decide how much information we wish to share about 
ourselves, with whom and for what purpose.*/

Source: https://ec.europa.eu/commission/presscorner/detail/en/ip_21_2663

**

This statement is not mentioned in the ARF.

An additional important *security consideration *needs to be addressed:

*      Collusions between **holders *(natural persons), which is 
difficult to support while at the same time the "*collection 
limitation*" privacy principle is considered.

This can be illustrated by the following example:

       Can Alice (12) collude with Bob (25) to access to a verifier 
delivering age-restricted services or products (e.g., like the condition 
of being over 18) ?
      Since Bob is over 25, he can obtain some "proof" that he is over 
18.  Can Alice (12) can advantage of this proof to access to 
age-restricted services or products ?

> Would you like to propose your idea in the current text (github issue 
> or PR) about the possibility to enable this technology?

On page 45 from COM(2021) 281 final, 
(https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52021PC0281) 
there is the following statement:

            "  A strengthened *privacy-by-design approach* could yield 
additional benefits since the wallet would not require intermediaries
             in the process of asserting the attributes, thus enabling 
the citizen to communicate directly with the service and credential 
providers".

Every IETF draft now includes both a *Security Consideration* section 
and a *Privacy Consideration *section. There is no such sections in ARF 
1.0.X.

Since ARF 1.0.X has not listed any privacy principle, it could not 
follow a *privacy-by-design approach.*

Before defining technical solutions, requirements would first need to be 
identified and agreed. At the moment, none of the five experiments is 
considering
the previously identified privacy principles (nor the above security 
consideration).

There should first be an agreement to add both a *Security 
Consideration* section and a *Privacy Consideration *section to the ARF.

Another consideration has been raised: the cryptographic algorithms 
being used should be quantum resistant.

This is a good wish but nobody knows when this would really be needed.

BBS+ is not believed to be quantum resistant. However, if one-time 
digital signatures are considered, they can be quantum resistant
(e.g., using SHA-3 and Lamport signatures). This would natively prevent 
verifiers to use the public key present in a credential proof to link 
accesses from
the same holder on different servers. This would mandate to issue 
batches of credentials in advance, which is only considered at a 
possible /option/
at the moment. This would also prevent using a "digital credential 
serial number" to perform a linkage between different digital proofs.

For signing digital credentials, the FIPS 204 (DRAFT) 
MODULE-LATTICE-BASED DIGITAL SIGNATURE STANDARD might be considered.

This does not mean in anyway that these algorithms should be used *now*, 
but it would be good to already know which kinds algorithms will be usable
when it will become really necessary to achieve quantum resistance.

> I mean, the current text satisfies the security requirements, in 
> addition to this we can explore and enable additional methods, in 
> particular when these brings additional benefits.
>
>   * A major section is missing: "*Privacy considerations*".
>
>
> yes, the best is yet to come ��

When doing a *privacy-and-security-by-design *approach*, *once the model 
and the key actors have be identified, these two sections should be 
filled-in first.

:-)

>
>   * One of many privacy principles is:  "unlinkability between verifiers".
>
>
> yes. The scope of this specs is providing a "static" way to give a 
> verifiable proof. In the privacy consideration I would start with the 
> sotry of Giuseppe that presents his credential of org affiliation to 
> an RP, giving org name, entitlements and position. Having the url and 
> the index of the revocation status of that credential, the RP is 
> technically able to continuosly check that Giuseppe is still emploied 
> in that organization, even outside of a resonable time windows for the 
> authorized  authentication/session.
>
> then, the scopes of this draft is all about revocation and tracking 
> prevention about the revocation checks. The problem of linkability 
> belongs to the credential and not to the status attestation (if I 
> didn't miss anything).

Let us now come back to Status Attestations when using one-time digital 
credentials.
Let us consider two cases: whether the status attestation request is 
done by the holder or by the verifier.

1) If the status attestation request is done by the holder, this means 
that it is online and in such a case, it could ask for a batch of 
one-time digital credentials
      with short expiration dates without the need to request Status 
Attestations.

2) If the status attestation request is done by the verifier /and if the 
server able to provide Status Attestations is different from the server 
issuing the digital credential/,
     then a query to that other server will prevent the issuer to know 
where the digital proof has been presented by the holder. This would 
allow the holder to get
     digital credentials with longer expiration dates.

Seen from the wallet, the following strategy would be used:

  * If the wallet knows that it is on-line, it will use or request a
    digital credential with a short expiration date.
    This will avoid the verifier to make a call when it receives the
    digital proof.

  * If the wallet knows that it is off-line, it will use an already
    stored digital credential with a long expiration date.
    If the server able to provide Status Attestations is, in fact, not
    really independent from the server issuing the digital credential,
    the linkability between verifiers will be limited to servers
    accessed using NFC. Hence, the risk will be mitigated.

Both types of digital credential will then have their own merits.

> Yes, I will, The sections Rationale and Privacy Consideration are the 
> most funny and we'll continue on those. Thank you for the hints, I 
> appreciate!

In this rather long email, you have further hints.

:-)

Denis

>
>
> ------------------------------------------------------------------------
> *Da:* Denis <[e-mail]>
> *Inviato:* giovedì 18 gennaio 2024 19:25
> *A:* demarcog83 <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>; Giuseppe De Marco 
> <[e-mail]>; oauth <[e-mail]>
> *Oggetto:* Re: [SPICE] [OAUTH-WG] OAuth Digital Credential Status 
> Attestations (typo)
>
> 	
> Non si ricevono spesso messaggi di posta elettronica da 
> [e-mail]. Informazioni sul perché è importante 
> <https://aka.ms/LearnAboutSenderIdentification>
> 	
>
> Questa email arriva da un mittente insolito. Assicurati che sia 
> qualcuno di cui ti fidi.
>
> Giuseppe,
>
> You are perfectly right, I read your draft too quickly.
>
> 1) The text mentions near the end:
>
>     OAuth Status List can be accessed by a Verifier when an internet
>     connection is present.
>
> This does not correspond to the flows of the figure.
>
> 2) The text states:
>
>     " The proof of possession MUST be signed with the private key
>     corresponding to the *public key* attested by the Issuer
>     and contained within the Credential".
>
> What about the support of "blinded link secrets" and "link secrets" 
> (used with anonymous credentials) ?
>
> 3) A major section is missing: "*Privacy considerations*".
>
> One of many privacy principles is:  "unlinkability between verifiers".
>
> If or when the status attestation allows to support this privacy 
> principle, it should be indicated how it can be supported.
> If or when it does not, this should be mentioned as well.
>
> Denis
>
>> Ciao Denis,
>>
>> thank you for the quick reply and for your contribution.
>> The scope of the current draft is to provide a verifiable artifact 
>> that give the proof that a specific credential is active, then not 
>> revoked.
>>
>> From your sequence diagram I read a digital credential issuance, 
>> while this is not in the scope of the draft.
>> best
>>
>>
>> Il giorno gio 18 gen 2024 alle ore 10:26 Denis <[e-mail] 
>> <mailto:[e-mail]>> ha scritto:
>>
>>     Typo: Change:"proof _*or*_ origin of wallet instance"
>>     into        : "proof _*of*_ origin of wallet instance".
>>
>>     The figure has been corrected below.
>>
>>     Denis
>>
>>>     Hi Giuseppe,
>>>
>>>     The current figure in the Introduction from
>>>     draft-demarco-status-attestations-latest is:
>>>
>>>     +-----------------++-------------------+
>>>     || Requests Status Attestation ||
>>>     ||---------------------------->||
>>>     | Wallet Instance || Credential Issuer |
>>>     || Status Attestation||
>>>     ||<----------------------------||
>>>     +-----------------++-------------------+
>>>
>>>
>>>     +-- ----------------++----------+
>>>     || Presents credential and||
>>>     |Wallet Instance| Status Attestation| Verifier |
>>>     ||---------------------------->||
>>>     +-------------------++----------+
>>>
>>>     IMO, using the vocabulary agreed during the last BoF video
>>>     conference, this figure should be modified as follows:
>>>
>>>
>>>     +------------++-------------------+
>>>     || Requests *Digital Credential* ||
>>>     || and presents proof of knowledge of ||
>>>     || either a private key or a link secret ||
>>>     || and proof *of* origin of wallet instance | Credential Issuer |
>>>     | Holder |--------------------------------------->||
>>>     ||| |
>>>     ||*Digital Credential*||
>>>     ||<---------------------------------------||
>>>     +------------++-------------------+
>>>
>>>
>>>     +-- ---------++-------------------+
>>>     || Presents *Credential proof*||
>>>     | Holder|| Verifier|
>>>     ||--------------------------------------->||
>>>     +------------++-------------------+
>>>
>>>     Denis
>>>
>>>
>>>>     Hi Hannes,
>>>>
>>>>     Thank you for your quick reaction and also to Orie for sharing.
>>>>     I've submitted the draft, here:
>>>>     https://datatracker.ietf.org/doc/draft-demarco-status-attestations/
>>>>
>>>>     <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-demarco-status-attestations%2F&e=bcb9f84b&h=6cfb1966&f=n&p=y>
>>>>     Regarding the term Attestation: good point. We have decided to
>>>>     use this term since in several IETF and OpenID drafts this term
>>>>     seems pretty established, the term Attestation is found at
>>>>     least in the following specifications:
>>>>       - Attestation based client-authentication (it's in the title)
>>>>       - OpenID4VC High Assurance Interoperability Profile with
>>>>     SD-JWT VC (wallet attestation)
>>>>       - OpenID for Verifiable Presentations - draft 20 (verifier
>>>>     attestation)
>>>>       - OpenID for Verifiable Credential Issuance (section "Trust
>>>>     between Wallet and Issuer": Device Attestation)
>>>>
>>>>     Meantime in the eIDAS Expert group this term is going to be
>>>>     changed to "Wallet Trust Evidence".
>>>>
>>>>     <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-demarco-status-attestations%2F&e=bcb9f84b&h=6cfb1966&f=n&p=y>
>>>>
>>>>     I don't have a strong opinion on what would be the best
>>>>     semantic for this, I just have realized the functional
>>>>     difference between a Digital Credential and an Attestation:
>>>>     the first requires the user to be authenticated and give
>>>>     consent for using the secure storage. The second is obtained
>>>>     with a machine2machine flow where no user interaction is
>>>>     required, the secure storage is not required, no user
>>>>     information is contained in it since the subject is the wallet
>>>>     instance and not the user, it cannot be (re)used without the
>>>>     cryptographic proof of possession. Probably a discussion could
>>>>     start about this term aiming to align several specifications on
>>>>     the same terminology. I could say that Status Attestation is a
>>>>     specific artifact defined for a specific context, other
>>>>     attestations can be defined outside the functional perimeter of
>>>>     this specification. Let's talk about it, it doesn't matters
>>>>     changing terms (eventually mindsets on perceivable meanings).
>>>>
>>>>     Here I share some notes I picked along the last two months
>>>>     about this brand new individual draft:
>>>>
>>>>     - it is related to digital credential only, I don't expect to
>>>>     use it in legacy infrastructure different from wallet. I really
>>>>     don't need this kind of mechanism in OIDC or any other
>>>>     traditional infrastructure since these doesn't show the privacy
>>>>     issues the wallet ecosystem has;
>>>>     - it would interesting mentioning in the introduction that's
>>>>     pratically an ocsp stapling like mechanism, just to give some
>>>>     context (credit: Paul Bastien);
>>>>     - The Rationale section needs to clarify better problems and
>>>>     solutions, where it seems that the problem does not exist or
>>>>     that it is weak. A review is necessary to clearly bring the
>>>>     benefits;
>>>>     - Editorials mistake are still along the reading.
>>>>
>>>>     thank you for your time and interest,
>>>>     best
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     Il giorno mer 17 gen 2024 alle ore 21:06
>>>>     <hannes.tschofenig=[e-mail]
>>>>     <mailto:[e-mail]>> ha scritto:
>>>>
>>>>         Hi Guiseppe, Francesco, Orie,
>>>>
>>>>         @Orie: Thanks for sharing the draft.
>>>>
>>>>         As a quick reaction: It would be good to invent a new term
>>>>         for “attestation” in draft-demarco-status-attestations.html
>>>>         because this term is already widely used in a different
>>>>         context (see RFC 9334).
>>>>
>>>>         @Guiseppe and Francesco: It would be great if you could
>>>>         submit your draft to OAuth or SPICE for discussion.
>>>>
>>>>         Ciao
>>>>
>>>>         Hannes
>>>>
>>>>         *From:*OAuth <[e-mail]
>>>>         <mailto:[e-mail]>> *On Behalf Of *Orie Steele
>>>>         *Sent:* Mittwoch, 17. Jänner 2024 19:07
>>>>         *To:* [e-mail] <mailto:[e-mail]>
>>>>         *Cc:* oauth <[e-mail] <mailto:[e-mail]>>
>>>>         *Subject:* [OAUTH-WG] OAuth Digital Credential Status
>>>>         Attestations
>>>>
>>>>         Hello Digital Credential Enthusiasts,
>>>>
>>>>         See:
>>>>         https://peppelinux.github.io/draft-demarco-status-attestations/draft-demarco-status-attestations.html
>>>>         <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fpeppelinux.github.io%2Fdraft-demarco-status-attestations%2Fdraft-demarco-status-attestations.html&e=bcb9f84b&h=09ac1782&f=n&p=y>
>>>>
>>>>         Note the use of the term digital credential, and the
>>>>         alignment to CWT based credentials and CWT based credential
>>>>         status lists.
>>>>
>>>>         As a quick summary of the editors draft above:
>>>>
>>>>         It is basically a refresh-token-like approach to dynamic
>>>>         state, where the holder retrieves updated state from the
>>>>         issuer at regular intervals, and can then present that
>>>>         dynamic state directly to the verifier.
>>>>
>>>>         This eliminates the herd privacy and phone home issues
>>>>         associated with W3C Bitstring Status Lists.
>>>>
>>>>         And it informs the holder of dynamic state, so the digital
>>>>         wallet can provide a better user experience.
>>>>
>>>>         However, an issuer (government or ngo) could use the
>>>>         interval of requesting dynamic state, to track the
>>>>         holder... so the guidance from
>>>>         https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/
>>>>         <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-steele-spice-oblivious-credential-state%2F&e=bcb9f84b&h=31ec3f83&f=n&p=y>
>>>>
>>>>         Is also relevant to this draft.
>>>>
>>>>         I also learned that
>>>>         https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
>>>>         <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-sd-jwt-vc%2F&e=bcb9f84b&h=1dd20f32&f=n&p=y>
>>>>
>>>>         Has defined a new property for expressing "Verifiable
>>>>         Credential" "type" `vct`, which is different from how W3C
>>>>         defines credential types.
>>>>
>>>>         W3C uses the expanded IRI for the graph node type, based on
>>>>         the JSON-LD context.
>>>>
>>>>         For example with:
>>>>
>>>>         {
>>>>           "@context": [
>>>>             "https://www.w3.org/ns/credentials/v2
>>>>         <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.w3.org%2Fns%2Fcredentials%2Fv2&e=bcb9f84b&h=f582aa55&f=n&p=y>",
>>>>             "https://www.w3.org/ns/credentials/examples/v2
>>>>         <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.w3.org%2Fns%2Fcredentials%2Fexamples%2Fv2&e=bcb9f84b&h=09fd0c99&f=n&p=y>"
>>>>           ],
>>>>           "id": "http://university.example/credentials/1872
>>>>         <https://urlsand.esvalabs.com/?u=http%3A%2F%2Funiversity.example%2Fcredentials%2F1872&e=bcb9f84b&h=a4458b13&f=n&p=y>",
>>>>           "type": ["VerifiableCredential", "ExampleAlumniCredential"],
>>>>           ...
>>>>         }
>>>>
>>>>         The credential type in RDF becomes
>>>>         "https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential
>>>>         <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.w3.org%2Fns%2Fcredentials%2Fexamples%23ExampleAlumniCredential&e=bcb9f84b&h=d975b89f&f=n&p=y>"
>>>>
>>>>         Which is different from "ExampleAlumniCredential" in
>>>>         JSON... More evidence that RDF leads to developer confusion
>>>>         regarding safe typing.
>>>>
>>>>         The OAuth solution does not have this confusing issue, they
>>>>         set the type explicitly:
>>>>
>>>>         {
>>>>          "vct":
>>>>         "https://credentials.example.com/identity_credential
>>>>         <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fcredentials.example.com%2Fidentity_credential&e=bcb9f84b&h=4de83001&f=n&p=y>",
>>>>          "given_name": "John",
>>>>          "family_name": "Doe",
>>>>          "email": "[e-mail] <mailto:[e-mail]>",
>>>>          "phone_number": "[phone]",
>>>>          "address": {
>>>>            "street_address": "123 Main St",
>>>>            "locality": "Anytown",
>>>>            "region": "Anystate",
>>>>            "country": "US"
>>>>          },
>>>>          "birthdate": "1940-01-01",
>>>>          "is_over_18": true,
>>>>          "is_over_21": true,
>>>>          "is_over_65": true,
>>>>          "status": {
>>>>             "status_attestation": {
>>>>                 "credential_hash_alg": "S256",
>>>>             }
>>>>          }
>>>>         }
>>>>
>>>>         Regards,
>>>>
>>>>         OS
>>>>
>>>>         -- 
>>>>
>>>>         *ORIE STEELE
>>>>         *Chief Technology Officer
>>>>         www.transmute.industries
>>>>         <https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.transmute.industries&e=bcb9f84b&h=5399df5d&f=n&p=y>
>>>>
>>>>         <https://urlsand.esvalabs.com/?u=https%3A%2F%2Ftransmute.industries%2F&e=bcb9f84b&h=1f9092b6&f=n&p=y>
>>>>
>>>>         _______________________________________________
>>>>         OAuth mailing list
>>>>         [e-mail] <mailto:[e-mail]>
>>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>>         <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&e=bcb9f84b&h=b6441af9&f=n&p=y>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     OAuth mailing list
>>>>     [e-mail]  <mailto:[e-mail]>
>>>>     https://www.ietf.org/mailman/listinfo/oauth  <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&e=bcb9f84b&h=b6441af9&f=n&p=y>
>>>
>>>
>>>
>>
>