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 to oauth-le...@ietf.org
