Hi Giuseppe,
We are on different tracks.
There is however a common point in our two approaches: "however, we
assume that the Wallet Instance had an internet connection within the
last 24h".
However, there is no need to present an "OAuth Status Attestation" to a
verifier.
IMO, neither the "Token Status List", nor to the "OAuth Status
Attestations" are the right way to address two privacy considerations:
"Unlinkability between verifiers" and "Untrackability by digital
credential issuers".
Anyway, none of these two approaches would be usable with digital
credentials signed using BBS+.
A single solution able to work in all cases would be preferable.
It can be supported by including an additional field in a digital
credential: a policy identifier.
A policy identifier included in a digital credential would indicate that
this digital credential, when stored in a wallet, is still under the
control of its digital credential issuer.
An I-D would be necessary (and sufficient) to define such policy identifier.
Denis
Ciao Denis,
OAuth Status Attestation was born because of some different approches
with the oauth status list token, I really would like to have a single
specification with the two approaches.
I report below and explain the main differences between the status
attestation and the status list token.
Taken from status list editor's copy draft
> This (Status List Token) allows for the Status List Token to be
hosted by third parties or be transferred for offline use cases.
it is not clear how:
- the token is rquested and obtained and used
- why it would be hosted by a third party
- the meaning of "transferred"
AFAIK this token reference a status list, with url and index, allowing
a RP to control over time the status of a credential.
It is not clear the scope of this token, in my assumption it represent
a long lived attestation of the historical status of a credential and
that's fine, but doesn't protect user privacy against revocation
status checks over time by unallowed RP.
Here the summary of the razionale behind OAuth Status Attestation
Use Case Scenario:
- A Verifier needs to check the status of a given Credential only
during the presentation flow.
- A Verifier is not allowed to check the status of a Credential over
time (after it was presented by the Holder), due to some privacy
constraints.
- No internet connection is available during the presentation phase
(however, we assume that the Wallet Instance had an internet
connection within the last 24h).
The idea:
The Credential Issuer provides the Wallet Instance with a Status
Attestation, which is bound to a Digital Credential. This allows the
Wallet Instance to present it, along with the Digital Credential
itself, to a Verifier as proof of the Digital Credential's non-revocation.
Merging the two approaches or extending OAuth Status List with OAuth
Status Attestations is always possibile if the authors wants do this,
I want do this if resonable to you and the WG as well,
best
Il giorno mer 7 feb 2024 alle ore 09:03 Denis <denis.i...@free.fr> ha
scritto:
Hi Guiseppe,
In your reply, you cut the main content of my original text and
hence you didn't reply to it.
In addition, you missed to pay attention to the email I sent
yesterday in my response to "I-D Action:
draft-ietf-oauth-status-list-01.txt".
I copy some parts of it below:
Another approach would be to consider that it is not the job
of the verifiers to check the “non-revoked” status of the
digital credentials they verify,
but that it is the job of the Holder (application). This would
be a “Holder centric” approach.
The Holder (application) needs to be a Trusted Application
(TA) that can be trusted by the digital credential issuer to
effectively control
and limit the use of some cryptographic keys and that cannot
be modified by an individual. A “digital identity wallet” is
the prime example of a TA.
In the real-life, a “*digital identity wallet*” is supported
by a smart phone or a tablet which will usually be online as
soon as some network is locally available.
When a digital credential is requested by a Holder at the
initiative of an individual, the base URL of the digital
credential issuer needs to be provided.
Such base URL can be built-in the downloaded Holder
(application), added when a revision of that Holder
(application) is available or manually entered by the individual.
An access point to contact the digital credential issuer can
be derived from the base URL of the digital credential issuer.
Once a digital credential has successfully been downloaded by
the Holder, this access point can be used by the Holder to
dialogue with the digital credential issuer
as soon as the smart phone or tablet is online.
During this dialogue, if some entity asked to a digital
credential issuer the revocation or the suspension of a
digital credential still within its validity period,
the digital credential issuer can freeze (i.e. suspend) the
use of that digital credential. A policy may be put in place
to say that if no contact has been possible
with a digital credential issuer during some period of time,
the use of each digital credential issued by that digital
credential issuer will be frozen by the Holder.
As a consequence, *if a digital credential has been able to be
used by a Holder, this means that it has not been frozen*.
A digital credential can later be unfrozen by its digital
credential issuer.
If there is a desire to freeze all the digital credentials
stored in an app, the TA Manager of that app would be in a
position to do that.
In the context of the “Issuer-Holder-Verifier model”, the
above descriptions are sketches of possible approaches that
highlight the fact that,
the "Token Status List" approach might not be the best way,
nor the simplest way, to support the two following privacy
properties:
“Unlinkability between verifiers“ and “Untrackability
by**digital credential issuers”.
Theses approaches are alternatives to
draft-demarco-status-attestations-01 and to the"Token Status List"
approach that would be simpler to implement.
Also note that, at the moment,
draft-demarco-status-attestations-01 does not contain a "Privacy
considerations" section.
Denis
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 works 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
