[OAUTH-WG] Re: SD-JWT linkability

[Tom Jones <[e-mail]>]

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]
>