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
