VPs are not reused AFAIK. thx ..Tom (mobile)
On Mon, Jan 22, 2024, 4:41 PM Watson Ladd <watsonbl...@gmail.com> wrote: > It could be a resused one obtained from a different context. Does that > matter? Depends on application. There's also a question of what it > means the subject processed it: people don't process VCs, their > computers do. (Hence the terminology of User Agent, not user, in the > W3C) > > > > On Sun, Jan 21, 2024 at 4:46 PM Tom Jones <thomasclinganjo...@gmail.com> > wrote: > > > > I should have added - if you get a verifiable presentation from a wallet > with a verifiable credential - it is my understanding that the VP is proof > possession - in the sense that the VC has been processed by the subject to > create the VP. > > > > I started to collect some information about that here - but it is far > from complete. > https://tcwiki.azurewebsites.net/index.php?title=Verifiable_Presentation#Full_Text_or_Meme > > > > ..tom > > > > > > On Sun, Jan 21, 2024 at 1:03 PM Tom Jones <thomasclinganjo...@gmail.com> > wrote: > >> > >> Technically oauth is about authorization not authentication. And > technically attestation is provided by rats and not oauth. So if you think > that you are confused, so is everyone else at this point. > >> > >> thx ..Tom (mobile) > >> > >> On Sun, Jan 21, 2024, 11:51 AM <d...@waugh.com> wrote: > >>> > >>> Hi Tom et al. > >>> > >>> Earlier this or last week someone wrote about the possibility of > looking at things from a relying party's perspective. > >>> > >>> As a relying party I need a method for a user to prove who and what > they are or have. Hence the user needs to present evidence as proof of who > they are and in what capacity or holding they are presenting. > >>> > >>> I have been very involed in SSI and verfiable credentials (VC). Which > is becoming a major way of presentiing evidence as proof. > >>> > >>> VCs are cryptographic proofs for a relying party. However the relying > party also needs proof of who is presenting. WShen you combine the two you > now address proof of possession problem which has been the underlying > weakness of public key cryptography. > >>> > >>> I was not trying to be misleading. I was responding to the discussion > below regarding " digital proof, digital credential, secure and privacy > preserving fashion, collusion between holders, collection limitation, > privacy principles, unlinkability between verifiers and more. > >>> > >>> I have done a lot of work in this area and believe have addressed the > proof of possession issue of public key cryptography because I can > cryptographically and privately bind a users biometrics with both their > public and private keys and can embed the same with veriable credentials. > Whereas when I see the OAuth work it seems to be trying to create an audit > trail rather than solving the proof of posession by the original > client/wallet initiating the transaction. > >>> > >>> As I said I was not trying to be misleading. At the same time I do not > see the current OAuth track as solving this underlying proof of possesion > problem that is needed by the relying party. > >>> > >>> Best > >>> > >>> Don > >>> > >>> And for the record I am not a technologist. I am a person who tries to > solve business problems. > >>> > >>> > >>> > >>> On 2024-01-21 11:08, Tom Jones wrote: > >>> > >>> yes - i see that's what you are doing and think it is not only wrong, > but misleading. > >>> Somehow words like trust and proof are given technological definitions > by technologists that do not reflect the words existing meaning, but seek > to gain reflected credence by their use in technological contexts. . > (like proof -> a cryptographic ability that is verifiable) > >>> Perhaps you don't care that these are incorrect uses of the word? > >>> > >>> ..tom > >>> > >>> On Fri, Jan 19, 2024 at 10:46 AM <d...@waugh.com> wrote: > >>> > >>> You present evidence as proof. > >>> > >>> > >>> On 2024-01-19 12:50, 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 <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> > >>> Inviato: giovedì 18 gennaio 2024 19:25 > >>> A: demarcog83 <demarco...@gmail.com> > >>> Cc: sp...@ietf.org <sp...@ietf.org>; Giuseppe De Marco < > gi.dema...@innovazione.gov.it>; oauth <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 > >>> > >>> 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/ > >>> > >>> 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". > >>> > >>> 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 > >>> > >>> 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/ > >>> > >>> Is also relevant to this draft. > >>> > >>> I also learned that > https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ > >>> > >>> 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://www.w3.org/ns/credentials/examples/v2" > >>> ], > >>> "id": "http://university.example/credentials/1872", > >>> "type": ["VerifiableCredential", "ExampleAlumniCredential"], > >>> ... > >>> } > >>> > >>> The credential type in RDF becomes " > https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential" > >>> > >>> 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", > >>> "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 > >>> > >>> _______________________________________________ > >>> 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 > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Astra mortemque praestare gradatim >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth