Hi Giuseppe,
I missed this
> 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".
here my notes
*Unlinkability between verifiers*
Status Attestations are designed to be privacy-preserving by not
requiring verifiers to*_directly_ * gather any additional information
from third-party entities.
The above sentence has nothing to do with unlinkability property between
verifiers.**
However, by adding the word "_*directly*_", it makes sense in the
context of "Untrackability by digital credential issuers".
**When conventional cryptography is being used, o*ne-time use digital
credentials allow to support this property.
*
This means that each verifier independently verifies the status of a
digital credential, though the status attestation, without needing to
interact with or reveal information to other verifiers or third-party
status list providers. This approach ensures that actions performed by
one verifier cannot be linked to actions performed by another
verifier, maintaining unlinkability between them.
*Untrackability by digital credential issuers*
Since Status Attestations can be verified statically without further
communication with the credential issuer or any other party, the
issuer cannot track when or where the digital credential is being
verified. This is in contrast to models where the verifier must query
a central status list or the issuer directly, which would allow the
issuer to track the usage of the digital credential. By providing all
necessary information within the Status Attestation itself, it ensures
that the issuer cannot track the verification activities related to a
specific digital credential.
These mechanisms are integral to the design of OAuth Status
Attestations, aiming to enhance privacy and security in the
verification of digital credentials by minimizing potential privacy
risks associated with the verification process
*
*
*When wallets are being used, revocation checking mechanisms are
absolutely *_*unnecessary*_.
When wallets are not being used, the whole system becomes insecure.
However, when the Holder requests a digital credential to the Issuer,
this requires the use of a specific protocol
(preferably using ASN.1/DER) that can demonstrate:
* that the digital credential request comes from a wallet that has
"specific characteristics", AND
* that the public key or the Blinded Linked Secret indeed originates
from that wallet.
Denis
thank you for having solicitated these aspects, I'll brings these few
notes in the privacy consideration section as well,
really appreciate your mindset Denis,
best
Il giorno mer 7 feb 2024 alle ore 14:12 Giuseppe De Marco
<demarco...@gmail.com> ha scritto:
Ciao Denis,
I agree with you until I find that the presentation/credential
format has the feature to attest its (non-)revocation. I was a BLS
signature evangelist at least two years ago. Working in the
government field, I am now required to use formats that are
globally recognized and standardized (please don't delve into
this; I mentioned it just to be honest with you).
According to this awareness, we, along with other authors and
implementers, need a revocation checking mechanism that is
agnostic to the format and scope of the subject to which the
status is attested and completely privacy preserving.
Both Status Lists and Status Attestations are suitable for
different use cases and solve specific problems. That's why they
exist, taking into account the design principle of being agnostic
to the subject format. Merging them into a single draft would be
the ideal solution. However, if this is not possible and at the
same time people require an OCSP stapling-like approach, OAuth
Status Attestations are justified in their existence.
I took your notes:
- todo: privacy considerations section
- 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.
I'll put my hands on the specs before IETF in brisbane (asap).
If you're interested in improving this brand-new specification and
considering how you might implement it, any contribution from your
side is appreciated and will be taken into account, both now and
in the future. To ensure your contributions are not lost in email
threads, please consider opening issues here:
https://github.com/peppelinux/draft-demarco-oauth-status-attestations/issues
I just open several issue to keep track of your hints,
thank you Denis!
Il giorno mer 7 feb 2024 alle ore 12:12 Denis <denis.i...@free.fr>
ha scritto:
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
