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.
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/.
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.
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 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.
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".
Denis
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 <[email protected]> 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 TEEcan 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 -- [email protected]
To unsubscribe send an email to [email protected]
