Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
Great question. I will give my 2 cents: proof -> a cryptographic ability that is verifiable signature -> proof of control of a private key. presentation -> proof of control of a private key that is bound to a signature (SD-JWT Presentation with key binding) presentation -> also just forwarding a credential (SD-JWT Presentation without key binding). evidence -> claims or attributes of a system being observed, usually collected prior to credential issuance evidence -> credentials or presentations used as input to identity proofing, and prior to credential issuance OAuth and RATS use "attestation" differently. OAuth and W3C use "presentation" differently. RATS uses the term "Endorsement" for places where OAUTH uses the term "Attestation". OS On Fri, Jan 19, 2024 at 11:50 AM Tom Jones wrote: > > 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 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
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
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 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
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
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
Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations (typo)
Hi Tom, I know that many standards editors are tasked to solve actual real life use cases but the existing standards do not suffice their requirements. Writing good standards is hard work and I think people usually don't do it without real needs. 18 Jan 2024 18:44:08 Tom Jones : > > The big problem is that standards bodies all over the spectrum are creating > attestations without even bothering to see what is happening in other > communities. The verifier will have many attestations to choose from and will > thus choose to do nothing with any of them. Perhaps it is time to ask a > verifier what problems they have instead of telling how to fix problems they > don't have currently? If it is really this hard to get this new stuff to > work, perhaps the new stuff is not well-designed to begin with? ..tom > > > On Thu, Jan 18, 2024 at 1:27 AM Denis wrote: >> 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/ 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://datatracker.ietf.org/doc/draft-demarco-status-attestations/]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
