[OAUTH-WG] Re: SD-JWT linkability

[Denis <[e-mail]>]

Carsten wrote:

      (...) it is impractical for a wallet to make this kind of
    judgement for each issued credential.

Carsten is correct : a wallet /which is an application /cannot make any 
kind of judgement.
However a human-being, i.e., an End-user that has the control over an 
Holder (application)
can make different kinds of judgments.

The major problem is that the End-User is not identified or considered 
in the draft.

Section 10. Privacy Considerations indicates:

*The privacy principles of [ISO.29100] should be adhered to.*

but the document is ignoring the content of this ISO 29100.

In the draft, the reference to this ISO standard is "ISO/IEC 29100:2011".
However, this reference is incorrect as ISO/IEC 29100:2011 has been 
withdrawn by ISO and replaced by ISO/IEC 29100:2024
ISO/IEC 29100:2011 is no more publicly available.

ISO 29100:2024 has recently been made publicly available by ISO free of 
charge.
There is no direct link to a pdf document, as you need to acknowledge 
the copyright conditions from ISO.

So ISO 29100:2024 is available using the  following six steps:

    1) You first go on the following page:
    https://standards.iso.org/ittf/PubliclyAvailableStandards/
    2) You search for the character string "29100",
    3) You click on the line that has been found: Information technology
    — Security techniques — Privacy framework
    4) You agree with the ISO conditions :

        You are about to download a document protected by copyright.
        When you download (an) ISO publication(s) from this site, you
        must accept the ISO Customer Licence Agreement (“Licence
        Agreement”),
        excluding clauses 2. Watermark, 5. Paper copies, and 6. Codes
        and Graphical Symbols (and their Collections).

    5) you get a zipped file of the document,
    6) you need to unzip the file.

The reference to ISO 29100 should be updated in section 13.2.  
Informative References

At the minimum, the "consent and choice " principle from ISO 29100:2024 
- Information technology — Security techniques — Privacy framework
should be considered and mentioned in the draft. It would be worthwhile 
to add privacy principles that apply to the Verifiers.

Paul wrote:

    To me, SD-JWT includes a thourough privacy consideration section on
    unlinkability which is way beyond what other IETF specifications
    have done is looks sufficient to me.

I don't believe that the current draft sufficiently address privacy as 
it it ignoring the presence of the End-user and the content of ISO 29100.

Privacy is first an End-user concern. The Holder should support the 
choices made by the End-user (once the End-user will have been 
sufficiently informed).
When the Holder is capable of proposing some choices, the End-user 
should have the ability to approve one of these choices or to deny all 
of them.
This is based on the principle of "Consent and choice" which is the 
first of the eleven privacy principles listed on page 14 in clause 6.2.

Yes, the data flows between the three roles happen between applications, 
but the data flows originating from a Holder
should only happen if the End-user has given his consent at some point 
of time.

The root of the problem comes from the fact that the term "End-user" is 
not present in the draft and is not illustrated on Figure 1:
SD-JWT Issuance and Presentation Flow*. *Figure 1 should be corrected as 
follows :
*
+------------+*
*||*
*|Holder|<--- End-user*
*||*
*+------------+*

Once the End-Users will be introduced into the Figure as well as into 
the draft, the definition of an Holder which currently is:

*Holder:An entity that received SD-JWTs from the Issuer and has control 
over them.In the context of this document, the term may refer to the 
actual user, the supporting hardware and software in their possession, 
or both..*

would need to be modified so that the application can be dissociated 
from the End-user that has the control over the Holder (application).
Afterwards, the document will be much more understandable.

I do know that this terminology problem originates from the VCDM 1.0 
document from W3C which is making the same confusion.
VCDM 2.0 is a data model, it is not an Architecture document. The 
document has forgotten that these exchanges happens because
they are normally done with the consent of the User (while some 
exchanges could be done maliciously by the Holder without
the consent of the End-user ... but this is another story).

Denis

> Standardization does not enable legal solutions – that`s job of 
> legislators but standardization shall recognize existing 
> standardization on records management which is affected here. Acc. to 
> ISO 15489, ISO 30301 (ISO Tc 46 Sc 11) the definition of retention 
> period is in responsibility of records manager and mostly not defined 
> in advance. Means your idea “The retention and disposal periods for 
> that information should be clearly defined, enforced, and communicated 
> to data subjects” won`t work
>
> ““Personal information gathered for a specific purpose should not be 
> used for other purposes without the person's consent.” àdecision by 
> records manager acc. ISO 15489, ISO 16175 and ISO 30301.
>
> Long Story short: Technical requirements shall follow international 
> standards – this is what your idea Tom lack off
>
> *Von:* Tom Jones <[e-mail]>
> *Gesendet:* Dienstag, 17. Dezember 2024 18:41
> *An:* Steffen Schwalm <[e-mail]>
> *Cc:* Tom Jones <[e-mail]>; Pierce Gorman 
> <[e-mail]>; IETF oauth WG <[e-mail]>
> *Betreff:* Re: [OAUTH-WG] Re: SD-JWT linkability
>
> *Caution:* This email originated from outside of the organization. 
> Despite an upstream security check of attachments and links by 
> Microsoft Defender for Office, a residual risk always remains. Only 
> open attachments and links from known and trusted senders.
>
> Legal requirements can only be adjudicated by legal means. The common 
> approach in standards developments should be to enable a legal 
> solution not to mandate it.
>
> thx ..Tom (mobile)
>
> On Mon, Dec 16, 2024, 11:14 PM Steffen Schwalm 
> <[e-mail]> wrote:
>
>     In > 80% of use cases the retention period is not defined by law
>     but defined by records manager after receiving the information
>     from holder. So data retention won`t work. For those thinking
>     about GDPR: Yes possible within GDPR too as GDPR does not require
>     definition retention during collection of PII. Means only strong
>     human-centric ID of verifier and purpose possible
>
>     “Personal information gathered for a specific purpose should not
>     be used for other purposes without the person's consent.” àdoes
>     this mean an administration is not allowed to give information
>     about location collected for one purpose to the police for
>     another? This would legally not work
>
>     *Von:* Tom Jones <[e-mail]>
>     *Gesendet:* Dienstag, 17. Dezember 2024 02:26
>     *An:* Pierce Gorman <[e-mail]>
>     *Cc:* [e-mail]; IETF oauth WG <[e-mail]>
>     *Betreff:* [OAUTH-WG] Re: SD-JWT linkability
>
>     *Caution:* This email originated from outside of the organization.
>     Despite an upstream security check of attachments and links by
>     Microsoft Defender for Office, a residual risk always remains.
>     Only open attachments and links from known and trusted senders.
>
>     I could have been more clear. If a verifier is asking for
>     information, it must include strong human-centric ID of verifier,
>     data retention and purpose.  That is not currently possible with
>     the VP. This makes the OID4VP an unethical means to request
>     information. See the following:
>
>     https://www.acm.org/code-of-ethics
>
>     Only the minimum amount of personal information necessary should
>     be collected in a system. The retention and disposal periods for
>     that information should be clearly defined, enforced, and
>     communicated to data subjects. Personal information gathered for a
>     specific purpose should not be used for other purposes without the
>     person's consent.
>
>     Clearly information holders can do what they want with their own data.
>
>     Peace ..tom jones
>
>     On Mon, Dec 16, 2024 at 11:22 AM Pierce Gorman
>     <[e-mail]> wrote:
>
>     I think I disagree.  I assume an SD-JWT in a VP could be
>     volunteered by a Holder initiating a transaction.  i.e., the
>     relying party Verifier didn’t request the VP.
>
>     The example I would give is an enterprise making a phone call and
>     using SIP INVITE method Identity header to carry an SD-JWT VP.
>
>     In the US, the TRACED Act law and several FCC mandates require
>     voice calls in the Public Switched Telephone Network (PSTN) to be
>     authenticated using information contained in a JWT.
>
>     The basic type of JWT required is defined in RFC 8225 “PASSporT:
>     Personal Assertion Token” and is carried in the SIP INVITE method
>     Identity header.
>
>     There is also an I-D in the IETF STIR working group which proposes
>     use of an SD-JWT: Verified STI Persona (aka VESPER).
>
>     I assume the VP could be encoded by value in the SIP Identity JWT
>     or could be passed via a DID document reference (in theory).
>
>     Pierce
>
>     CONFIDENTIAL
>
>     *From:*Tom Jones <[e-mail]>
>     *Sent:* Monday, December 16, 2024 12:50 PM
>     *To:* Watson Ladd <[e-mail]>
>     *Cc:* IETF oauth WG <[e-mail]>
>     *Subject:* [OAUTH-WG] Re: SD-JWT linkability
>
>
>     	
>
>     You don't often get email from [e-mail]. Learn
>     why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
>     	
>
>
>     	
>
>     *EXTERNAL EMAIL*
>
>     The entire premise of SD-JWT in a VP transaction is basically
>     fraudulent as there is not sufficient information in the VP to
>     allow the user to make an informed consent decision. It gives the
>     illusion of user control without the ability to deliver on the
>     promise. For this proposal to have any value to the user it must
>     be part of a transaction that tells the user agent (wallet) who is
>     asking for the data and what the purpose of the request is. Absent
>     that, this give the impression of user control of release of data
>     without the fact.
>
>     BTW - the idea of dealing with the UX of the transaction is
>     admirable, but there are no UX people involved in the discussion.
>
>     Peace ..tom jones
>
>     On Wed, Dec 11, 2024 at 5:01 PM Watson Ladd
>     <[e-mail]> wrote:
>
>     Dear all,
>
>     I'd like to propose the following edit to resolve the concerns I have
>     around endorsing dangerous applications of SD-JWT:
>
>     Delete last two lines of
>     https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/451/files
>     in 1338 and 1339
>
>     Add new paragraph right before the end of the section.
>
>     "When disclosures include information easily understood to be
>     identifying, users intuitive view of what they are revealing largely
>     matches the underlying technical reality. In cases where the
>     information being disclosed is not identifying, SD-JWT
>     MUST NOT be used as this confusion leads to users making the wrong
>     choices. Applications cannot assume Verifiers behave properly (RFC
>     3514) and MUST analyze the consequences for such linkage with each
>     credential that could be used."
>
>     I think this agrees with many of the comments made about my initially
>     stronger edit, while addressing the core danger.
>
>     Also, it seems this section only really treats issuer/verifier despite
>     promising more. Do we need to rework it?
>
>     Sincerely,
>     Watson Ladd
>     -- 
>     Astra mortemque praestare gradatim
>
>     _______________________________________________
>     OAuth mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> OAuth mailing list [e-mail]
> To unsubscribe send an email [e-mail]