I think the proposal should be renamed as optimized data mining. AIs around the world will love the idea. Herd privacy is utter nonsense and has been from the beginning.
On Tue, Feb 6, 2024, 5:08 AM Denis <denis.i...@free.fr> wrote: > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > 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
