Comments on draft-ietf-oauth-status-list-01.txt
The text states:
*11.****Privacy Considerations*
*
**11.1.Issuer tracking and Herd Privacy*
The main privacy consideration for a Status List, especially in the
context of the *Issuer-Holder-Verifier model,*
is to prevent the Issuer from tracking the usage of the Referenced
Token when the status is being checked.
However, the Issuer-Holder-Verifier model is not defined in this document.
A description existed in “draft-ietf-oauth-selective-disclosure-jwt”,
but this I-D has expired which means that this I-D cannot be referenced
any more.
The past definition for a Holder in this I-D was:
Holder:An entity that received SD-JWTs (2.1) from the issuer and has
control over them.
In this past definition, the use of the word “entity” was not crystal
clear. There is a need to indicate that *a Holder is an **application*
under the control of an *individual *and that some choices will done by
the Holder (application) but also by the individual using that application,
in particular choices and consents from the individual. An alternative
definition would be:
Holder: Software application running on a device or on hardware that
manages digital credentials under the control of an individual.
The original "3 roles model" was described in the VCDM 1.0 document from
the W3C. It was only a "Data Model" for two (important) pieces of data.
In order to build protocols for the “Issuer-Holder-Verifier model”, a
threat analysis should first be done on this model.
Unfortunately, this has not yet been the case. Such analysis would lead
to identify security properties and privacy properties
that may be desirable to be met. This would have allowed to build one or
more architectures using a “privacy and security by design” approach.
Among various properties, two privacy properties that apply to the 3
roles model are: “Unlinkability between verifiers“ and “Untrackability
by**digital credential issuers”:
“*Unlinkability **between verifiers*” means that two verifiers
should not be able to know whether two digital proofs are presented
by the same individual.
“*Untrackability **by****digital credential issuers*” means that a
digital credential issuer should not be able to know to which
verifiers a digital credential
that it has issued to a Holder, or derivations from it, will be
presented.
The current approach is driven by a CRL-like mechanism proposal. This is
only a part of a puzzle that might be belong to a wider picture,
but, before, it would be better to know how the whole picture looks
like. Instead of a bottom-up approach, a top-down approach would be
preferable.
The current approach is considering the case where the “non-revoked”
status of a digital credential would be obtained by the verifier.
This is a “verifier centric” approach.
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”.
The “Issuer-Holder-Verifier model” is currently not within the scope of
the OAuth WG. This work-item could be progressed either in the OAuth WG,
if its scope is expended, or by a WG issued from the SPICE BoF, if a WG
gets formed from it.
For the time being, in a future revision of this I-D, the privacy and
security considerations that apply to the OAuth 2 Framework
and to the “Issuer-Holder-Verifier model” should be clearly separated.
Denis
P.S. In section 11.4, there is the following sentence:
"In this case, every Referenced Token MUST have a dedicated Status
List entry."
Adding explanations for using the verb "MUST" would be desirable.
Internet-Draft draft-ietf-oauth-status-list-01.txt is now available. It is a
work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
Title: Token Status List
Authors: Tobias Looker
Paul Bastian
Christian Bormann
Name: draft-ietf-oauth-status-list-01.txt
Pages: 25
Dates: 2024-02-05
Abstract:
This specification defines status list data structures for
representing the status of JSON Web Tokens (JWTs) [RFC7519] and CBOR
Web Tokens (CWTs) [RFC8392]. The status list data structures
themselves are also represented as JWTs or CWTs.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-status-list-01.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-status-list-01
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
