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

[Tom Jones <[e-mail]>]

Proof seems to be yet another term for which we already have other terms.
Can anyone explain the difference between:
proof
presentation
evidence.

..tom


On Fri, Jan 19, 2024 at 4:28 AM Denis <[e-mail]> wrote:

> 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. *
> *      So 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]> <[e-mail]>
> *Inviato:* giovedì 18 gennaio 2024 19:25
> *A:* demarcog83 <[e-mail]> <[e-mail]>
> *Cc:* [e-mail] <[e-mail]> <[e-mail]>; Giuseppe De Marco
> <[e-mail]> <[e-mail]>; oauth
> <[e-mail]> <[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]> 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]> 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]> *On Behalf Of *Orie Steele
> *Sent:* Mittwoch, 17. Jänner 2024 19:07
> *To:* [e-mail]
> *Cc:* oauth <[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]",
>  "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]
> 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 [e-mail]://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]
> https://www.ietf.org/mailman/listinfo/oauth
>