[OAUTH-WG] Re: SD-JWT linkability

[Paul Bastian <[e-mail]>]

That's because it isn't. SD-JWT has no direct dependency or relation to 
any OpenID spec.

On 17.12.24 02:37, Watson Ladd wrote:
>
>
> On Mon, Dec 16, 2024, 5:26 PM Tom Jones <[e-mail]> 
> wrote:
>
>     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:
>
>
> I didn't understand the draft to be limited to OID4VP. Any sort of 
> presentation would have the same issues.
>
>
>     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]