[OAUTH-WG] Re: SD-JWT linkability

[Watson Ladd <[e-mail]>]

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