Hey D Il giorno mer 12 giu 2024 alle ore 13:54 Denis <denis.i...@free.fr> ha scritto:
> Hi Giuseppe, > > Thank you for your response that was sent rather early today. :-) > > This draft might be paving the way for *a* solution that might be adopted > for the EUIDW > ... or even paving the way for *THE* solution that will be adopted for the > EUIDW. > I bring solutions after having evaluated the requirements, I found an important privacy concern that forced me to push the nth proposal. I strongly believe that revocations must be classified by different use cases and that there might be different revocation mechanisms for different use cases. EUDIW represents only a part of what will be at the end the wallet paradigm. > The solution proposed in the draft is purely technically based and cannot > be considered > to be the most effective way to address the *concerns of the end-users*. > let's see what happen, an idea may helps the born of other ideas. I don't consider myself neither the most effective solution architect over here, therefore you can imagine how modest could be my contribution. Keep things moving will help things moving, like this conversation. Time will show us the achievements. > As this topic might be progressed within the SPICE WG (if it is formed), > it could be considered > as a narrowed field of vision with short-term benefits without considering > the whole picture. > yes, the wallet paradigm could take a decade to be properly consolidated in the digital identity field. It seems that at least 5 years was already spent. > You have not commented the section 6) that proposes a different approach > taking into consideration the whole ecosystem that, anyway, > will be necessary to consider to support TAs providers, secure OS > providers, Rich OS providers and TEE providers. > > The security of a chain is composed of the security of each of the > elements of a chain. Without a TA (and the other components > that need to be present to support it), many kind of security problems > cannot be correctly solved. > I agree with you, however these copmponents sounds outs from the status assertions since they must be defined in the trust model and trust framework and specifications dedicated to the trust establishemnt, like ... Ok, you know. > > I have indicated why the mechanism I propose has several major advantages *for > the end-users, *over the use of Digital Credential Status Attestations. > In particular, it allows to *suspend* at once all the credentials > contained in a wallet instead of *revoking* them one-by-one. > > watch this: https://github.com/peppelinux/draft-demarco-oauth-status-assertions/pull/61 > > Now, let us switch to a vocabulary problem. The definition of a holder in > the W3C Verifiable Credentials Data Model is the following: > > *holder* > A role an entity might perform by possessing one or more verifiable > credentials and generating verifiable presentations from them. > Example holders include students, employees, and customers. > > While the definition is roughly correct, the examples are incorrect. The > first key word is "role" while the second key word is "generating". > It is impossible for a human being to *generate* a verifiable presentation > because the processing power and the memory size of a human brain > is insufficient. Hence a holder cannot be a student, an employee or a > customer. > > In the same way, taking the OpenID definition which is: > > *Holder* > An entity that receives Verifiable Credentials and has control over them > to present them to the Verifiers as Verifiable Presentations. > > it is impossible for a human being to *present* a verifiable presentation > because the processing power and the memory size of a human brain is > insufficient. > > A solution to this problem would be to use two different terms: Holder > Application and Holder. > > *Holder application* > A role an application might support when controlling the use of one or > more Digital Credentials and generating Digital Presentations from them. > > *Holder* > An entity that has the control of a Holder Application. Examples include > citizens, students, employees or customers. > > Note: I am reusing the terms from the SPICE charter, i.e., "Digital > Credentials" and "Digital Presentations", instead of the terms used by W3C > "Verifiable Credentials" and "Verifiable Presentations". > This is an issue on openid4vci, since I desidered to align to the openid specs even if ... the hilaurous conversation with Daniel in Rome I mentioned. > > Denis > see you G
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
