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 t
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)
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 who
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
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 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 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 limita
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
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 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 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 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/
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
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 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 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 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 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 Cr
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
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 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 > 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 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 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 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 i
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
VPs are not reused AFAIK. thx ..Tom (mobile) On Mon, Jan 22, 2024, 4:41 PM Watson Ladd 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 > 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 > 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 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 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 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. >
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
There are at least 2 kinds of vp. W3C has them and they can be secured or not. SD-JWT has them, and they can have key binding or not. An sd-jwt without key binding is indistinguishable from a credential except for looking at the unprotected disclosures. SD-JWT has a section on forwarding presentations, that talks about redacting fields and presenting in a cases where key binding is not required. Key binding is basically the secured version of a W3C VP, but restricted to a single credential, instead of multiple credentials. Key binding is not required afaik. Therefore presentation can be forwarded / reused. OS On Tue, Jan 23, 2024, 12:51 AM Tom Jones wrote: > VPs are not reused AFAIK. > > thx ..Tom (mobile) > > On Mon, Jan 22, 2024, 4:41 PM Watson Ladd 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 >> 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 >> 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 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 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 wrote: >> >>> >> >>> Hi Giuseppe, >> >>> >> >>> Ciao Denis, >> >>> >> >>> Thank y
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
That's far worse than I ever imagined. It seems like it's bloody well useless. ..tom On Tue, Jan 23, 2024 at 5:48 AM Orie Steele wrote: > There are at least 2 kinds of vp. > > W3C has them and they can be secured or not. > > SD-JWT has them, and they can have key binding or not. > > An sd-jwt without key binding is indistinguishable from a credential > except for looking at the unprotected disclosures. > > SD-JWT has a section on forwarding presentations, that talks about > redacting fields and presenting in a cases where key binding is not > required. > > Key binding is basically the secured version of a W3C VP, but restricted > to a single credential, instead of multiple credentials. > > Key binding is not required afaik. > > Therefore presentation can be forwarded / reused. > > OS > > On Tue, Jan 23, 2024, 12:51 AM Tom Jones > wrote: > >> VPs are not reused AFAIK. >> >> thx ..Tom (mobile) >> >> On Mon, Jan 22, 2024, 4:41 PM Watson Ladd 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 >>> 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 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 wrote: >>> >>> >>> >>> You present evidence as proof. >>> >>> >>> >>> >>> >>> On 2024-01-19 12:50, Tom Jones wrote: >>> >>> >>> >>> >>> >>> Proof seems to b
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
Hi Denis, sorry for the delay, below by points. > A *digital credential* may be presented to a verifier long after it has been issued. In the abstract we say what's the status attestation. Probably it's an editorial suggestion from you to say what's the substantial difference between the digital credential and its status attestation. the subject of this specification is the status attestation, not the digital credential which the status attestation is referred to. > Entity that relies on the validity of the *digital proof* presented to it. verifiers validate the digital credentials and these can have different revocation check mechanisms (or no one). I'd keep the digital credential as the most important landmark for the verifier, where the status attestation is a sort of annex of that. > This does not correspond to the flows of the figure. The picture contains two distinc moments: the provisioning of the attestation (that currently in the specs is online only) and the presentation of it (that wors fine in the offline scenario). I'll look forward for other interactions about this specs, probably by voice it would be everything more easy to explain, thank you for the hints! best ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
Ciao Tom, Forgive the delay in replying to you, I rarely find pleasure in discussion as in moments of sharing with you. I feel every responsibility for not being able to describe its purposes in the introduction of the specification, this is clear to me from your comment below. > That's far worse than I ever imagined. It seems like it's bloody well useless. ..tom I'll try in a sort of summary of things to keep attentioned 1. I don't assume that RPs will check revocations or require this check, I know that according to some trust frameworks some credential types requires to be revoked therefore the RPs should check this to attests the validity of the credentials. 2. there might be short lived digital credentials that makes revocations useless. If the user authentication is required (with any complexity belongin to the required LoA) doing user authentication every 24h would represent an UX killer. 3. there might be refresh token to obtain credentials without requiring the user (re)authentication. This is partially true, since accessing to a secure storage requires the local user authentication and consent. In addition to this, refresh tokens are out of control of the user and this might not be compliant to some national privacy regulations in this particular field of digital identity wallet, where a refreh token would provide a brand new bearer token and therefore a brand new credential, identifying the user, without any control of the user. If we put the control of the user, will end up again in a UX pain, every 12-24-48 hours ... these oauth status attestation can be stored even outside of the secure storage. Me and the co-authors an contributors are doing an important change: providing a proof of possession of the credential instead of the credential within the status attestation request. The wallet instance periodically obtains these status attestaions without any direct use of the digital credentials, but only their proof of possession. When the user starts the wallet, when the local authentication is required, the private keys will be used to sign the credential pop for the status attestation request. Once obtained: these can be used for offline flows as well. The subject of this status attestation is the credential, not the user, nor the wallet instance. This is another property I find interesting. I'm sure your point of view will help me better define these concepts and consequently the implementations, best Il giorno mar 23 gen 2024 alle ore 18:27 Tom Jones < thomasclinganjo...@gmail.com> ha scritto: > > That's far worse than I ever imagined. It seems like it's bloody well > useless. ..tom > > > On Tue, Jan 23, 2024 at 5:48 AM Orie Steele > wrote: > >> There are at least 2 kinds of vp. >> >> W3C has them and they can be secured or not. >> >> SD-JWT has them, and they can have key binding or not. >> >> An sd-jwt without key binding is indistinguishable from a credential >> except for looking at the unprotected disclosures. >> >> SD-JWT has a section on forwarding presentations, that talks about >> redacting fields and presenting in a cases where key binding is not >> required. >> >> Key binding is basically the secured version of a W3C VP, but restricted >> to a single credential, instead of multiple credentials. >> >> Key binding is not required afaik. >> >> Therefore presentation can be forwarded / reused. >> >> OS >> >> On Tue, Jan 23, 2024, 12:51 AM Tom Jones >> wrote: >> >>> VPs are not reused AFAIK. >>> >>> thx ..Tom (mobile) >>> >>> On Mon, Jan 22, 2024, 4:41 PM Watson Ladd 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 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 wrote: >>> >>> Hi Tom et al. >>> >>> Earlier this or last week someone wrote about the possibility of looking at things f
