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 <thomasclinganjo...@gmail.com> 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 <denis.i...@free.fr> 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 <denis.i...@free.fr> <denis.i...@free.fr> >> *Inviato:* giovedì 18 gennaio 2024 19:25 >> *A:* demarcog83 <demarco...@gmail.com> <demarco...@gmail.com> >> *Cc:* sp...@ietf.org <sp...@ietf.org> <sp...@ietf.org>; Giuseppe De >> Marco <gi.dema...@innovazione.gov.it> <gi.dema...@innovazione.gov.it>; >> oauth <oauth@ietf.org> <oauth@ietf.org> >> *Oggetto:* Re: [SPICE] [OAUTH-WG] OAuth Digital Credential Status >> Attestations (typo) >> >> >> Non si ricevono spesso messaggi di posta elettronica da >> denis.i...@free.fr. 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 <denis.i...@free.fr> 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= >> 40gmx....@dmarc.ietf.org> 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 <oauth-boun...@ietf.org> *On Behalf Of *Orie Steele >> *Sent:* Mittwoch, 17. Jänner 2024 19:07 >> *To:* sp...@ietf.org >> *Cc:* oauth <oauth@ietf.org> >> *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": "john...@example.com", >> "phone_number": "+1-202-555-0101", >> "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 >> OAuth@ietf.org >> 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 listOAuth@ietf.orghttps://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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
