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

Reply via email to