Ciao Denis, thank you for the time spent in reading and writing, I see several points that express an enormous gratitude from me for your contribution. I add my feedbacks below.
Il giorno mar 11 giu 2024 alle ore 18:12 Denis <denis.i...@free.fr> ha scritto: > > The text of the email states: > > "there are several use cases for revocations, each of which is addressed, > either wholly or partially, in these specifications". > > While there are indeed several use cases for revocations, I don't believe > that each of them can be addressed > either wholly or partially in these specifications *to the best interest > of the end-users*. > Yes, we're still on it. The sin I see is that we have started first with technical solutions and specifications before having a clear view about the legal and privacy requirements. Something that we're still picking along the road. Regarding the technical limitations of the current technologies: today I cannot get more than this. *1) In section 3, a Holder is defined as* : > > Holder: An entity that receives Verifiable Credentials and has control > over them to present them to the Verifiers as Verifiable Presentations. > > This definition is ambiguous as it may be understood to be a human-being > (and it is the case later on ...) . > The word "entity" should be changed into "application". > I remember an (hilarius) conversation made with Daniel Fett in Rome, during the OSW, about the question mark <<Who is the Holder?>>. Who is the Holder of the milk the user bought in the market: The fridge in the house or the user that owns the fridge? Despite the hilarious, but still philosofical, question, the definition of holder was taken from the openid specs ( https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-terminology ) This was made to not go too much far from something already shared, agreed and developed within the community. *2) The document should first identify the reasons for using a revocation > mechanism* > > In my context I have also the revocation request made by the user, and other flows pertaining the revocation when made by authentic sources or other authorities (jurisdicional ...). The text today wants to define the approach to issue and verify status assertions. For the requirement to define a credential revocation request with the credential issuer as the audience a brand new draft should born, since this should be neutral with the status check if list of assertions. good point anyway. > The term "Wallet Instance" is being used and is defined on page 4 as: > > The digital wallet in control of a User, also known as Wallet. > > So let us consider the use case of a Wallet. > > The current document is directly focusing on a technical mechanism without > telling what the problems to be solved are. > I can take this, good catch. I'd continue on this here: https://github.com/peppelinux/draft-demarco-oauth-status-assertions/issues/73 > Two entities can take the initiative of a revocation : either the owner of > a wallet (i.e., not the Holder) or the Issuer. > as mentioned above, also a jurisdictional trusted party, or the wallet provider that doesn't see the wallet instance no more compliant/secure. > > > Let us focus about the owner of a wallet and its relationship with his > wallet. > > The following situations can typically happen : > > (1) Where is my wallet ? I can't find it any more. Either I simply lost it > or somebody has stolen it. > (2) My wallet has indeed been stolen. I am sure about this, but I know > that the thief is not in possession of the authentication factor(s) to use > it. > (3) My wallet has indeed been stolen and unfortunately I do know that the > thief is in possession of the authentication factor(s) to use it. > > good conversation. I want to clarify that these are consideration that not necessarly could be included in the draft, since they go out of its scope. 1) the citizen can use an external service to be identified and therefore ask to the wallet provider the revocation of its wallet instance 2) still weak due to the infinite ways to "use" an hardware/software in an unconvetional way. The citizen still should ask the revocation ... 3) as the previous one > For each of these cases, should the owner of a wallet ask the Issuer to > revoke of his digital credential ? > > In the first case (1), let us suppose that the digital credential is > revoked. Using the Status Assertion mechanism, the revocation will remain > valid > approximately 24 hours. If five minutes after successfully asking the > revocation of that digital credential, the lost wallet is found again, > the digital credential cannot be used during the next 24 hours. A new > digital credential request must then be initiated. > If a suspension mechanism were available, the new digital credential > request would be avoided. > > In the case (2), if the Wallet has been found again a similar situation > applies. > If a suspension mechanism were available, the new digital credential > request would be avoided. > > In the case (3), a revocation for much more than 24 hours is needed. > A new digital wallet must be obtained and then after new digital > credential request must be initiated. > > It's up to the credential issuers decide the exp of the status assertions. there may be also future development upon this draft where also a RP could request a fresh status assertion, with exp in minutes. Suspection is something that Orie wants to bring in with the pending PR you find. There will be the possibility to add more details aside the boolean active/revoked currently iin use. Just to be clear: the scope of the document is not defining the lyfecycle of the credential but a mechanism to prove the non revocation. > *3) The current title of this draft is "OAuth Status Assertions". * > > The content of the draft is not specific to OAuth specifically. However, > Status Assertions are specific to the use of Digital Credentials. > > If a SPICE WG is created by the IESG (which should be known at the end of > this week), the title of this document would become: > > "SPICE Status Assertions". > > :-) > > I can buy this. Orie is asked to join in this conversation and confirm that we should continue change the name of the specs. Let's continue on this groove here: https://github.com/peppelinux/draft-demarco-oauth-status-assertions/issues/74 > More seriously, its title should rather be "Credential Status Assertions" > or "Digital Credential Status Assertions". > > > *4) In section 6. Proof of Possession of a Credential, the text states:* > > The essence of requiring proof of possession over the Credential through > the confirmation method, > such has proving the control of the cryptographic material related to a > Credential, is to ensure that the entity > in possession of the Credential can execute actions exclusively reserved > to the legitimate Holder. > > Note that the term "Holder" is used above in the sense of a person, > whereas a Holder is an application. > > On the contrary, this method *does not* "ensure that the entity in > possession of the Credential can execute actions > exclusively reserved to the legitimate owner of the Credential ". When a > selective disclosure of claims is being done, > PoP, as described, is *not* resistant to collaborative attacks between > individuals (that will be performed in practice > between collaborative Holders). > this is related to the pop of the credential for the status assertion request, not the presentation flow to an RP. SD is out of the scope of the status assertions > > > *5) In Section 15.3. Unlinkability and Reusability of Status Assertions, > the text states:* > > This design is pivotal in ensuring unlinkability between Verifiers, where > actions taken by one Verifier > cannot be correlated or linked to actions taken by another. > > This sentence sounds strange. An "action taken by one Verifier" will be > invisible to another Verifier unless the network is unprotected, > but it is assumed that TLS is being used. What is the problem for > correlating "actions" taken by a Verifier ? This sentence would need to be > reconsidered. > > it says that since there are no fixed audiences in the status assertions, a verifier obtainign a status assertion cannot know if that assertion was already used with another verifier or any information usefull to track its usage and or its audience > However, "unlinkability between Verifiers" usually means unlinkability > between *colluding* Verifiers that shall not be able to know that a same > end-user > made an access to a protected resource. > > Using SD-JWT, such property can be supported if a SD-JWT are used only > once. This should be mentioned in this section. > the same with the status assertions I agree that further clarification can be made: issue here, https://github.com/peppelinux/draft-demarco-oauth-status-assertions/issues/75 For the points above I'd leavethem to Giada and Amir and Francesco for anything interesting for the local wallet architecture and the credential lifecycle. thank you Denis! > > *6) An alternative method for the demonstration of the validity status of > a digital credential* > > This alternative method has been constructed considering all the > components of the ecosystem and in particular the wallet, > as well as all the phases prior to the placement of one or more credential > in a wallet. > > A Holder SHALL NOT be an application executed in an insecure environment. > > The typical use case is an application executed by a Trusted OS which is > supported by a TEE (Trusted Execution Environment). > > Asking one-by-one for the revocation of credentials takes time and is not > "user friendly". > > Instead of using the Status Assertion mechanism to revoke a credential > placed in a wallet, it is possible to suspend either > the use of one credential placed in a wallet or, much better, *to suspend > at once the use **of all the credentials placed in a wallet*. > > In case of a panic, it is much better to first *suspend* all the > credentials placed in a wallet and then to think more about what to do. > If, later on, the wallet is found again, then all the credentials placed > in the wallet can immediately be reactivated at the same time. > The Status Assertion mechanism is unable to accomplish this performance. > > Two cases need to be considered: > > - the wallet is used in an online environment where the Verifier is > accessed by the Holder using the Internet, or > - the wallet is used in a local environment where it is not connected > to the Internet. > > In the first case, this alternative method prevents the use of the wallet > in the *few seconds* following the demand from the individual > to suspend the use of the wallet. The Status Assertion mechanism is unable > to accomplish this performance. > > In the second case, the wallet can continue to be used during a lapse of > time of approximately 24 hours ... unless a connection of the wallet to the > Internet happens. > If no connection to the Internet happens during 24 hours then the > performance will be identical to the case of the Status Assertion mechanism > but if a connection occurs > the performance will be much better. > > In terms of security as well as in terms of ease of use for the > individuals, this approach is superior to the Status Assertion mechanism. > > The "magic" of this alternative mechanism is rather simple. While many > variations of it are possible the goal of this email > is not to make a detailed description of them. > > However, the idea is the following: > > 1) When the smart phone connects to the Internet, at any time, the > provider of the TEE can inform the Holder (application) > that it shall suspend the use of all the credentials. Later on, the > provider of the TEE can inform the Holder (application) > that it shall delete the credentials. > > 2) As long as the smart phone is NOT connected to the Internet, the Holder > (application) shall only allow the use of the credentials during 24 hours. > > This method does not require the use of any structure like a Status > Assertion but requires the development of a protocol between the Holder > (application) and the provider of the TEE. > > Finally, this method offers the major advantage of allowing the > development of Trusted Holder applications that *can be resistant to > collaborative attacks between individuals*, > in particular when a selective disclosure of claims is being used. > > Denis > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
