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 <thomasclinganjo...@gmail.com>
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
<pierce.gor...@numeracle.com> 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 <thomasclinganjo...@gmail.com>
*Sent:* Monday, December 16, 2024 12:50 PM
*To:* Watson Ladd <watsonbl...@gmail.com>
*Cc:* IETF oauth WG <oauth@ietf.org>
*Subject:* [OAUTH-WG] Re: SD-JWT linkability
You don't often get email from thomasclinganjo...@gmail.com.
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
<watsonbl...@gmail.com> 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 -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
